The Quiet Pressure of Joining a New Team

I've been doing this for a long time, and there's one feeling that still hasn't completely gone away. Whenever I join a new team, start working with a new client, or find myself taking on more responsibility, I still get that slightly uncomfortable feeling in my stomach. Butterflies is probably the closest description.

Earlier in my career, I assumed it came from not knowing enough. I figured experience would eventually make it disappear. After enough projects, releases, production issues, architecture discussions, and unfamiliar codebases, walking into a new environment would surely start feeling routine. It never really has.

The interesting part is that I don't think it comes from believing I can't do the job. I've been dropped into enough unfamiliar systems to know that I can usually figure things out. The first few days are always confusing, but I've learned to expect that. You don't know why certain decisions were made, which parts of the system everyone quietly avoids touching, which problems are technical and which ones are mostly historical, or even how decisions actually get made inside the team.

That uncertainty doesn't bother me nearly as much as it used to. What I still feel is something slightly different: I want the people who brought me in to feel like they made the right decision.

The first few weeks feel different

I've noticed that I operate differently when I'm new to a team. I pay closer attention, not just to the code but to everything around it. Who has context on a certain part of the system? Where do decisions actually happen? Which problems keep coming up? What does the team consider normal that might look unusual from the outside?

I also ask a lot of questions. Part of that is simply trying to understand the system, but part of it is resisting the temptation to immediately change things. When you come into an unfamiliar codebase with fresh eyes, it is easy to spot things you would have done differently: architecture, testing strategy, CI, abstractions, naming, processes.

What experience has taught me is that "I would have built this differently" usually isn't very useful when you've only been there for a couple of weeks. There is almost always context you haven't discovered yet. Maybe that strange abstraction exists because of a constraint that disappeared two years ago. Maybe that awkward workflow is supporting something you don't know about. Maybe the obvious cleanup has already been attempted and failed for reasons that aren't visible in the code.

So I try to understand first. At the same time, I naturally start looking for places where I can contribute. Sometimes that means fixing something small. Sometimes it means taking a messy problem and giving it enough structure that the team can make a decision. Other times it means noticing a gap in testing, tooling, or a development workflow and figuring out whether it is worth doing something about it.

Underneath all of that, though, there is usually the same thought: I want them to feel like bringing me here was a good decision.

That pressure has probably helped me in a lot of ways. It makes me prepare, listen carefully, ask questions instead of pretending I understand something, and think beyond the task directly in front of me. But it can also be exhausting, because there is always another part of the system you could understand, another problem you could help solve, and another way you could try to be useful.

At some point, wanting to contribute can quietly turn into feeling like you need to prove your value as quickly as possible.

When things are going well

Every once in a while, I get a bit of positive feedback about how I'm doing or hear that someone has appreciated my work. You'd think that would make the butterflies disappear, and sometimes it does. But I've also noticed that my reaction is often something closer to: Okay, now I need to make sure I live up to that.

It's a strange response when you think about it. Positive feedback is evidence that things are going well, so logically it should reduce the pressure. Instead, sometimes it raises the bar in my own head.

I don't think this is exactly impostor syndrome. I don't usually feel like I'm pretending to know things I don't or waiting for somebody to discover that I'm incapable of doing the job. It's closer to feeling responsible for the trust that has started to build.

That becomes more noticeable as the work becomes less about simply completing tasks. Earlier in my career, the feedback loop was often straightforward: did the feature work, did I fix the bug, did I finish what I said I would finish? As responsibilities grow, the things people rely on you for become harder to measure.

Can I make sense of an ambiguous problem? Can I identify a risk before it becomes expensive? Can I make a reasonable decision when there isn't an obviously correct answer? Can I explain the trade-offs clearly enough that someone else can challenge my thinking? Can the team rely on me when a problem doesn't fit neatly into a ticket?

There isn't always a green checkmark telling you that you got those things right.

What experience actually changed

For a long time, I assumed experience would eventually remove this feeling. What seems to have happened instead is that experience changed how I interpret it.

Earlier in my career, nervousness often felt like evidence that I wasn't ready. These days I see it more as a sign that I care about the outcome. The butterflies themselves aren't particularly useful, but some of the behaviors they produce can be.

They make me listen before proposing changes. They remind me that understanding the system is part of the work. They make me ask questions when something doesn't make sense and think more carefully about the consequences of a decision. In that sense, I don't necessarily want to get rid of the feeling completely.

The part I'm still figuring out is how to keep that useful edge without carrying all of the pressure that comes with it. Because trust isn't really built by having one impressive first week or finding the biggest problem in the codebase before everyone else.

Most of the time, it's built through much less dramatic things: understanding the context before suggesting a solution, following through on something you said you would do, admitting when you don't know the answer, making decisions you can explain, catching problems early, and helping other people get unstuck.

Doing those things consistently matters a lot more than trying to prove your value as quickly as possible.

I still get the butterflies when I join a new team. Experience didn't make them disappear. It just taught me that I don't have to respond to them by trying to prove everything at once.