Joining a New Company as a Senior IC

Table of Contents

At the end of 2022 I joined Circle as a Staff Engineer. Joining a new company as a senior individual contributor is a different challenge than joining as someone just starting out in their career. It’s not harder than joining as a new engineer; in both cases, there is uncertainty and pressure. But as a senior IC, it’s a different kind of pressure. I thought I would share a little bit about my experience, my anxieties, the expectations, the things I did right, and the things I’d like to do differently next time.

Challenging the Status Quo
#

One piece of advice I’ve always read about joining a new company is try not to make a lot of changes right away. It makes sense. After all, nobody likes it when a new manager joins and immediately tries to change the way everything is done, as if they alone have the magic formula for success. This certainly applies to senior ICs as well.

When you start at a new employer, you have zero political capital. As a senior IC, this can be a little bewildering. You’re likely coming from a place where you have lots of political capital, where you’re well-known by the people in charge, and where people listen when you have something to say. If you see a problem, you can speak up, and things will happen. At your new company, nobody knows who you are or trusts your opinion yet. You need to earn some credibility and make some allies before you can really make any impact. If you raise your voice now, there’s a big risk you’ll come off as a know-it-all, or you’ll rustle the feathers of people who are already aware of the issue and working on solutions. This time is also a great opportunity to challenge some of your own assumptions about best practices.

When I started at Circle, I was conscious about holding my suggestions, ideas, and criticisms until after I was finished ramping up. I kept a list of questions I had and problems I had noticed, thinking that I’d come back to these after I had ramped up and earned some trust. This turned out to be really effective because over time, I found a lot of my questions were answered just through day-to-day experience.

Even still, I found myself challenging the status quo and swimming against the stream in small ways.

I’ve actually seen this behaviour before from the other side. When I was at Amazon, we had a new senior engineer join our team and immediately throw himself behind something which wasn’t all that important or helpful. He was really set on replacing our Confluence documentation with a Docsify site. He built it up and made a big deal about it, and then it ended up just getting filled with a bunch of junk placeholder pages and little else. He also started an initiative to revamp our entire deployment process, which was a good idea, but he didn’t yet have enough context to understand why it was the way it was. He left not too long after; neither project was completed.

I have more empathy for this engineer now that I have experienced joining a new company as a senior IC. You want to hit the ground running, and there’s pressure to demonstrate you’re really a senior worth your salt. Challenging the status quo before you have enough context to really understand it is an easy trap to fall into.

Minor Annoyances
#

Some problems are just minor annoyances, or “it’s not how I would do it” problems. These are problems to avoid digging into because it spends political capital that you haven’t yet earned.

As a remote-first company, Circle makes heavy use of async communication, and especially Slack. I found one Slack channel particularly challenging because it was a mix of discussions with pull request notifications. The channel was quite noisy, and not very many of the notifications were relevant to me. I had a hard time keeping up with the discussions when I had to first sift through all the notifications. I figured it would be a quick and easy win to separate the notifications from the discussions, so I created a new channel for PRs.

This particular change got some positive feedback. However, I found out later that there were several other channels where PR notifications could appear. I didn’t bother creating corresponding PR-only channels, and nobody asked if I would. I take this as a signal that the separation wasn’t that valuable. I just wanted fewer notifications because I found it challenging!

At the time I was unaware, but the notifications were introduced based on employee feedback that it was difficult to get timely code reviews. In retrospect, this is a different problem that I could have focused on solving first. It’s a bigger, tougher, cultural problem that takes time and buy-in to properly address.

Real Problems
#

As a senior IC, it is my job to recognize when the status quo isn’t working, and to advocate for change. After about 6 months at Circle, I found I had enough context to actually start to recognize when something was a real problem versus just something that bothered me personally.

One thing I found was a real issue for engineers was the startup cost in bootstrapping their local development environment. In some cases, this could be upwards of 20 minutes. Using my 6 months of experience, and data on how big the impact was, I came up with a plan for improvements, and was able to articulate these well enough to get buy-in from others across the company. This resulted in a big reduction in local development cost, and bought me political capital and credibility that I could use later.

My takeaway from this experience is that it’s important to spend some time doing things in the standard company way, even if it’s not ideal, just to get a feel for how things work. After that, you can feel free to go off the beaten path, but you should have a good idea why you’re doing this and why the standard way doesn’t work.

Meeting your Coworkers
#

Joining a new company, it’s important to meet the people you will be working with, as well as the leaders in your org. I set up initial meetings with teammates and managers, and in each meeting I asked who else I should get to know. This was an effective strategy for generating a graph of organizational connections. I was also able to determine the key decision makers based on the names that came up most often. However, the list quickly became quite unwieldy! I met one-on-one with nearly 60 people in my first 12 weeks, an average of one per day. For a while, these meetings were invaluable. I got to learn a lot about my coworkers, their experience, and their opinions on many things.

After a certain time, the endless meetings became exhausting, and I felt like there were diminishing returns. And I still had several weeks worth of meetings scheduled! I was less invested in following meetings, and as a consequence, I got less out of them.

Next time I think I’ll meet as many people as I can in the first 3 weeks. After that, I’ll keep a priority queue of people to meet. But rather than setting up meetings weeks in advance, I’ll try to keep it organic or only schedule meetings for the current week. That way I can keep myself invested and cut it off when I’m starting to wane.

Ramping Up
#

I’ve read that it can take upwards of 3 months to a year from the time a new employee is hired to when they are a net positive investment. That’s not to say that you can’t complete tickets or contribute anything during the ramp-up period. But it does take a while to learn about the broader organizational context, grasp the business domain, grok the technical architecture, and get familiar with new tools and processes.

One thing that helped me ramp up was reading a lot. Aside from formal onboarding training, I went out of my way to find reading that gave me a broad understanding of the company. I perused pull requests, projects updates, OKRs, design documents, metrics, Slack threads, and other artifacts from across the organization. I read through the code of a number of applications just to get a feel for how they worked. The more I read, the more I understood about the company, the process, and the priorities.

Reading was one of the most valuable ways I spent my time during onboarding. Because of this, I was able to speak intelligently about current projects on other teams and how they overlap with my team. It helped me to understand the industry better, and what the company strategy was. It also gave me a clear, detailed understanding of what my team’s services do and how they work.

Part of the job of a staff engineer is to “keep your head up” and be aware of what others are working on. But there is also a cost to reading a lot: it takes a lot of time! During the ramp up period, this is acceptable since it’s expected that you’re coming up to speed. But after a while, I developed a really scary backlog of documents to read. I found I had to be judicious about which documents and pull requests I chose to read.

Doing Too Much
#

Joining a company as an experienced engineer, I felt pressure to immediately get involved in a lot of different things. I was afraid of “failure to thrive”, like I had to prove myself by making an immediate impact. But I didn’t yet have enough context to know what was important and what wasn’t. As a result, I found myself attaching to everything that came along. I said yes to way too much. I over-indexed on the first problem domain I worked on (after several months I learned that it wasn’t even all that important). And inevitably, I had to let go of some things in order to prioritize others.

Here is a small selection of some other things I dropped the ball on:

Getting involved with design reviews too early, and then having to back off because I had too many things on my plate
Trying to find cost savings for AWS bill, getting stuck due to lack of access, and giving up
Investigating new tools for project management, code coverage, continuous integration, etc.
Championing a security audit for our APIs
Introducing a dependency injection framework
Automatic code formatting

The biggest problem with doing too much was it undermined by credibility. I wasn’t the first person to help out when someone on my team had an issue because I was busy trying to catch up on things I had promised to do. I disappointed my senior leadership because I failed to deliver on some things I had been championing. It also caused me a lot of stress because things were being added to my todo list faster than I could clear them.

Next time, I would focus more on doing a few things well at the start. Take on a little bit of responsibility, and then deliver on that spectacularly. Then slowly add on new things as I come off the ramp-up curve and I learn more about what is important to the business.

Conclusion
#

I’ll end by summarizing the above into some pieces of advice for myself. Hopefully, next time I join a new company, I’ll remember to come back here and read them.

First, don’t challenge the status quo in the first few months after joining a company. Even if it seems like an easy win, it’s important to take time to understand the reasons why things are the way they are. Learn to do things using the current process before suggesting a change, even if only to better understand why your own method is better (see also: Chesterton’s Fence). Ask lots of questions, and make sure they’re intended in a genuine way (and not just “let me point out how bad this is and how much better I am”). At the same time, continue to keep your head up and look for non-obvious ways to improve the status quo. Just don’t suggest too many changes at once.

Second, meeting coworkers is important, but don’t overdo it. You’ll meet plenty of people in time. Focus on meeting your immediate and adjacent teams, leadership, and stakeholders. Limit introduction meetings to a few weeks.

Third, reading a lot is very important. Make time for reading, especially during the ramp up period, but remember that you won’t be able to read everything. Again, focus on your immediate and adjacent teams.

Finally, don’t try to do too much right away. Take on a little and deliver on it. Make a good first impression, and use the ramp up period to really ramp up, rather than getting too attached to the first opportunity you see. More opportunities will come in time, and with more context, you’ll be able to determine what really matters.

Challenging the Status Quo #

Minor Annoyances #

Real Problems #

Meeting your Coworkers #

Ramping Up #

Doing Too Much #

Conclusion #

Further Reading #