My First Month as a Newbie Staff Engineer

This is my first time working as a staff engineer at a new company, and the challenges I'm facing are genuinely different from before.

It's not that the role itself is especially hard — that's not why it feels difficult. It's because at my previous company, the path from senior engineer to staff engineer was itself a process of becoming familiar with the org structure, earning enough trust, and gaining the ability to push forward almost any project I wanted to. This time is very different. I'm in an environment I don't yet know well, still unaware of the processes and reasoning behind past technical decisions, yet in some sense I'm the person everyone highly expects to bring change. Even in my first week or two of conversations with colleagues, I could clearly feel people leaning in to listen closely to how I explained my thinking. Given these expectations, how do I take my first step?

When I thought about the angle to take, what I wanted to accomplish in the first month was: understand how the organization operates, get to know the history and current state of the local systems, and understand the collaboration dynamics of the teams that directly affect me.

Understanding, and Understanding Again#

As I usually do, I started from the onboarding process I'd just gone through. For the parts that were unclear or ambiguous, I dug through old documents to trace the context, gathered everyone's input, and proposed the simplest possible version. Then I iterated on it with the newly joined colleagues who came after me. What started as a casual move — because I have a habit of wanting to tidy things up whenever I notice inconsistency — was also meant to build a bit of rapport with the team through proposing and iterating on a minimal project. But since quite a few colleagues were joining the org, after checking expectations with the EM, I ended up leading a Tech Lead in building an onboarding standard for the whole engineering team, which got good feedback.

After onboarding in week one, I hit the company retreat right away; setting that aside, in my second week of actually working I did an initial code quality evaluation and shared it with the team at the weekly sync. I tried to use my usual research-driven approach to explain why certain things weren't good and why certain areas needed improvement, while also understanding their historical context along the way. Through these discussions I tested how much the team would accept my standards and looked for an initial way to collaborate.

I also put a lot of focus on 1:1 meetings — building relationships and gaining a deeper understanding of my colleagues, and giving both of us space to really talk. This helped me a great deal in understanding people's personal histories, work expectations, and recent challenges, and through these conversations I also found quite a few projects worth pushing forward.

Because of this, I had the chance to take on, right from my first month, a cross-department project that had been a headache for every team involved: through interviews I understood the project's original intent and both sides' current state and challenges, then proposed a new process and discussed it with everyone. I also got to talk directly with the leaders about the project, which doubled as a test of my communication style, then went to different departments' project meetings to explain it. Beyond helping resolve stakeholders' concerns to move the project forward, I also picked up a lot of interesting information that became material for my later engineering initiatives.

Engineering management in the AI era is of course also a major challenge of mine, and while it's a big part of what I'm building and leading, going into it here would run too long and risk going off-topic — so I'll write a separate piece analyzing and sharing my thoughts and strategy on that.

Trust Comes First#

Another staff peer told me during our 1:1 that the biggest challenge for a staff engineer joining a company is usually not technical — it's how to earn the team's trust after joining, in order to drive our initiatives and exercise leadership and mentorship within it, since as staff engineers we're expected to already be capable of handling technical challenges. What reassured him was that I gained trust surprisingly fast — beyond just handling team issues, people were already coming to me with problems. Why was that possible? When we discussed it, he pointed out it was thanks in large part to the foundation he'd already built for staff-engineer/engineer collaboration, the team's overall open-minded culture, and, of course, my own approach and strategy as well.

As mentioned earlier, I found projects worth pushing forward through extensive 1:1s with team members in my first month. For most projects, I don't jump straight in to participate unless their impact is too significant — otherwise I'd rather understand the org and the current situation a bit more before stepping in. But beyond that, there were also quite a few needs around vertical and horizontal communication within the team that I could help lead. For these opportunities, I talk directly with folks in meetings to clarify context and expectations, then send a followup invitation afterward. On one hand this reminds me of action items I need to handle; on the other, it also lets my engineers know — when discussing things with me — the standards and code of conduct I hold myself to regarding anything that affects the team. Of course, for conversations leaning toward career direction or personal matters, I let people set up time with me at whatever pace feels comfortable to them.

While the above isn't necessarily the whole picture of why trust builds quickly, I do think my past experience has helped a lot. I've always noticed how information gaps lead to misunderstandings when looking at different topics, and I've also benefited before from the value of information transparency. So at work I always want stakeholders to have enough information to understand the current situation: I try to leave clear meeting minutes and action items in the Slack channel after discussions in various meetings and projects, and when leading discussions with the team, I make a point of not being lazy about giving people extra "information that's actually readable." Maybe that's part of what helps everyone build trust faster!

The Fastest Way to Get Information#

A colleague nearby shared with me one day that he'd noticed the company's staff engineers always seem to find a direction to push forward even when the situation is still unclear — something he finds quite challenging himself, and he was curious how we do it.

The story behind the scenes, honestly, is that I have my own fears and worries too. The reason is that I know a staff engineer's influence can be huge, but as someone who — until now — had never joined a company directly as a staff engineer, facing these expectations and the authority and influence that come with them still makes me feel a bit uneasy.

Over this past month, whether in how I lead discussions or how I think through initiatives, what I see is the speed at which the team has changed because of me. I'm grateful for my teammates' trust and willingness to try things, but I also carry a good deal of trepidation — the unfamiliarity of a brand-new environment, including the shape of the organization and its people, sometimes leaves me uncertain whether I'm even doing the right thing. Still, I believe that with a faster feedback loop, I can take small steps, fail fast, and iterate quickly — as long as I can hold onto the mindset that iterating and revising is normal, I can keep finding direction together with the team and keep moving forward.

Influence is a double-edged sword. I hope that in the days ahead I can stay true to my original intent — finding the most comfortable way to collaborate to solve problems the whole team finds uncomfortable, and moving forward together with anticipation — and put my influence to good use.