The First Thing I Do When I Join a New Engineering Team

The first weeks at a new team are not the time to show what you know. They're the time to figure out where you actually are — and how to be useful as fast as possible.

The Urge to Prove You Belong

There's a specific kind of anxiety that kicks in when you join a new team as an experienced developer. You know things. You have opinions. You've seen what works and what doesn't. And you're aware, somewhere in the back of your mind, that the people around you are watching to see whether you're as good as they hoped.

The response to that anxiety is almost always wrong: try to contribute too fast, offer opinions too early, suggest improvements before you understand what you're working with.

I've done this. It doesn't land well. The team isn't wrong to be skeptical — you don't know what you think you know yet, because context changes everything.

Read Before You Write

The first thing I do with any new codebase is read it. Not to audit it. Not to find problems. Just to understand it.

I trace the core request lifecycle — from how a request enters the system to how a response leaves it. I look at the data model and try to understand what the system considers important. I read the tests to understand what guarantees the system makes about itself. I look at recent commits to understand where the team has been spending its time.

This takes several days, sometimes more. It feels unproductive. It isn't.

By the end of it, I have a mental model of the system that no onboarding document can give me. I know where the complexity lives. I know where the historical hacks are. I know what the team has been fighting with.

You can't improve something you don't understand. Reading is the understanding phase.

Ask About History Before Forming Opinions

Almost every legacy decision that looks bad has a reason behind it. The reason might be technical debt, or organizational pressure, or a constraint that no longer exists, or a mistake nobody ever fixed. But it almost certainly has a reason.

Before I form an opinion about something that seems wrong, I ask: "Help me understand how we ended up here." Not "why is this such a mess" — that's a judgment. A genuine question about history.

The answers are almost always informative. Sometimes the decision made perfect sense at the time and the world changed around it. Sometimes it was always a compromise and the team knows it needs to change. Sometimes I'm missing context that makes the decision obvious.

Curiosity before critique. It's a discipline, and it pays dividends in trust.

Find the Informal Knowledge

Every team has two sets of documentation: the official one and the real one. The official documentation lives in wikis and READMEs. The real documentation lives in the heads of specific people.

One of my first priorities is figuring out who has what knowledge:

• Who knows why the system is structured this way?
• Who remembers the incident that led to that particular guard clause?
• Who has context on the stakeholder relationships that shape technical decisions?

I find out by having conversations, not by sending a survey. I ask people to walk me through their part of the system. I listen for the things they mention as assumptions — those are usually the most important things, because nobody writes down what they assume everyone already knows.

Ship Something Small, Fast

Theory only gets you so far. The fastest way to understand a team's actual workflow — their review process, their deployment pipeline, their communication patterns — is to put something through it.

I try to ship something small in the first week. Not a feature. A bug fix, a documentation improvement, a small refactor that someone already identified as needed. Something where the outcome isn't the point — the process is.

I pay attention to everything: how long review takes, what kind of comments come back, what the deployment pipeline looks like, what breaks that I didn't expect. Every friction point is information about where the team spends energy.

A small first contribution is reconnaissance as much as it is work.

State What You Think You Know

After a few weeks, I have a model of the system and the team. I state it out loud: "Here's what I think I understand about how this works. Here's where I'm still uncertain." I share it with a senior teammate or the lead.

This does two things. First, it exposes the gaps in my model before I act on wrong assumptions. Second, it demonstrates that I've been paying attention — which matters more than people say.

The questions that come back from this exercise are almost always the most useful conversations I have in the first month.

Earn the Right to Suggest Changes

The moment when you've done enough of the above — when you understand the system, its history, its constraints, and the people who built it — is when your opinions start to have weight.

Not before. Not on day two, when you notice something that looks wrong. Day two opinion: "I'm curious about this — can you help me understand it?" Week six opinion, after you've shipped work and read the codebase and asked the history questions: "I think there's a problem here, and I have a specific suggestion for how to address it."

Same information. Very different reception.

The fastest way to become useful on a new team is to spend the first few weeks acting like you might not know everything yet — because you don't.