The first 90 days at a new job are weirdly load-bearing. The reputation you build in those three months sticks to you for years, sometimes for the rest of your time at the company. People decide, mostly subconsciously, whether you’re “the engineer who gets things done” or “the engineer who showed up loud and never quite recovered.” It is profoundly unfair. It is also how most workplaces work, so you may as well play it on purpose.
I’ve onboarded into four different companies now, two of them in Italy with a contratto indeterminato, two as a freelancer with my P.IVA. The cultures were completely different. The pattern of what went well, and what didn’t, was almost identical. So this is the quiet checklist I now follow whenever I start somewhere new. Nothing flashy. Just the things that, in retrospect, mattered the most.
Listen way more than you talk
For the first month, your default volume should be lower than feels comfortable. This is not about being meek. It’s about the basic information-theoretic fact that you don’t know enough yet to have useful opinions, and pretending otherwise is a tax on the people who do.
I once watched a senior hire join a team and, in his second week, declare in a meeting that the company’s data warehouse was “a mess” and they should switch from Postgres to Snowflake. He was not wrong about the mess. He was very wrong about how to make that case. He hadn’t yet talked to the person who’d built the warehouse, who happened to be the most respected engineer on the team and was sitting two seats away. He spent the next six months trying to recover credibility he had burned in ninety seconds.
The version of that engineer who would have succeeded asked questions instead. “I noticed we’re on Postgres for the warehouse layer. What were the trade-offs that led there? Are there parts of the workload that are starting to strain it?” Same observation. Completely different reception. The first version says “I’m smart and you’re behind.” The second says “I’m paying attention and I’d like to understand.”
For the first thirty days, default to questions. Save your strong opinions for when you’ve earned the room.
Ship something small and useful in week two
The single best move you can make in the first month is to ship something small. Not a refactor. Not a new system. Something tiny and visibly useful, ideally to a colleague, ideally within ten working days of starting.
I’m talking small. A broken README link. An obvious typo in a Slack alert. A flaky test that has been annoying everyone for six months and that you fixed in two hours because you read the stack trace carefully. A new entry in the runbook that clarifies which on-call rotation owns which alert.
The point is not the technical impact. The point is that you’ve now demonstrated three things to the team: you can find your way around the codebase, you can get a pull request through review, and you don’t need hand-holding to be useful. Those three signals, sent in week two, will save you a thousand awkward “how’s the new hire doing?” conversations between your manager and their peers.
The trap to avoid is going for something too ambitious as your first ship. A new feature, a new microservice, a new dashboard, anything that requires you to understand more of the system than you currently do. Save those for month two. Week two is the week of the small, satisfying, finished thing.
Document one thing nobody else has time to document
Every codebase has a long tail of “tribal knowledge.” The Airflow DAG that’s named one thing but does another. The dbt model that you have to run with a specific flag or it silently fails. The deployment step where you have to manually edit a config file because no one ever automated it. The Slack channel where the real ops conversation happens, separate from the official one in Jira.
The team that hired you knows all this. They’ve absorbed it over years. What they don’t have is the time, or honestly the motivation, to write it down. They already understand it. They forget that someone walking in cold has to discover it the hard way.
You, in your first month, are the only person on the team who is currently rediscovering all of this. So write it down as you go. Not in a thirty-page document. In a single Notion page, or a markdown file in the repo, or a thread in a docs channel. Whatever your team uses.
The first time I did this on a new team, I wrote about ten paragraphs of “things I tripped over in my first three weeks.” I posted it in a thread, half-apologetically, expecting it to get ignored. Instead, three engineers thanked me, two added their own missing pieces, and the doc became part of the official onboarding for the next hire. I had been there twenty-three days and I’d just made the team slightly better. That’s the move.
Have a 1:1 with everyone you’ll work with regularly
Within your first six weeks, schedule a 1:1 with each person you’re likely to interact with often. Not just your team. Your team’s PM. The data analyst who consumes your tables. The platform engineer who maintains the shared Airflow. The person on the adjacent team whose pipeline feeds yours. The designer if you have one. The QA lead. Anyone whose work touches yours.
These don’t need to be long. Thirty minutes is plenty. Bring a couple of soft questions and let the conversation breathe.
What to ask in those 1:1s
I have four go-to questions, and I’ve been using variations of them for years.
The first is “what does a good week look like for you?” This tells you what they actually care about, which is rarely what’s in their job title.
The second is “what’s the most frustrating thing about how we work today?” This surfaces real, concrete pain points that you might be able to help with later. People love an engineer who remembers their pet peeve and quietly fixes it three months later.
The third is “what would you want me to know that probably isn’t written down anywhere?” This is the gold-mine question. It gives them permission to share the unwritten rules, the recent history, the political fault lines, the “we tried that two years ago and it was a disaster” stories. You’ll learn more in the answer to this question than from a quarter of internal documentation.
The fourth is “is there anything I should be careful about in how I work with you?” People rarely volunteer their preferences unprompted. Asking shows you respect their time and want to make the working relationship easy.
What not to do, especially in month one
There’s an equally important list of things to avoid. I’ve made every one of these mistakes at least once.
Don’t propose a rewrite. Of anything. Even if the system is genuinely a mess. The people who built it had reasons, and the reasons were almost certainly more sensible than they look from the outside. You’ll find out what those reasons were by month three. Until then, your “we should rewrite this in [shiny tool]” is just noise. Worse, it tells the team you don’t yet understand the system well enough to know what’s load-bearing and what isn’t.
Don’t criticise legacy choices. There’s a junior-engineer reflex to look at a codebase and say “ugh, why did they do it like this?” Resist it. Sometimes the answer is “they didn’t know better.” More often, the answer is “they knew exactly what they were doing and you don’t have the context yet.” Either way, the comment doesn’t help.
Don’t start a “we should use X” campaign. Whatever the X is. dbt, Snowflake, Kubernetes, a new linter, a new framework. Every team has heard a hundred of these from a hundred new hires, and almost none of them survive contact with reality. If you genuinely think a tool would help, wait until you’ve shipped something with the existing tools first. Earn the right to suggest a change by demonstrating you understand the current setup.
Don’t refactor anything for the first month. Just don’t. The git blame is going to lead back to people who still work there. The patterns you find ugly are often the patterns the team has agreed on. If you really must touch something, ask in code review whether the existing convention is intentional. Nine times out of ten, you’ll learn something useful and shelve the refactor. The tenth time, you’ll have a real conversation about whether the convention should change, which is a much better place to be than a unilateral PR that sets the team against you.
The grace period is a real thing, use it
Here’s the upside of being new. You have, roughly, a one-month grace period where you can ask any question, no matter how basic, and nobody will judge you for it. After that, the grace period quietly closes, and asking the same question in month four feels much harder.
Use the window. Ask the dumb questions. Ask why the build pipeline is structured that way. Ask what an internal acronym means. Ask why a feature exists. Take notes. The questions you don’t ask in month one are the questions you’ll be quietly googling in month six, with a creeping sense that you should have figured this out by now.
Ninety days isn’t very long. By the end of it, if you’ve done the small things well, you’ll have shipped something useful, written something nobody else had time to write, met everyone you need to meet, and avoided the loud mistakes that take a year and a half to live down. You won’t be a star yet. Stars take longer. But you’ll be somebody the team is glad to have, and that’s the foundation everything else gets built on.