Five Tips for Joining A Company as a Staff Engineer

Published

November 26, 2024

Joining a new company is always a mix of excitement and nerves — kind of like starting a new level in a game. You’ve got the skills from your last role, but everything around you is different, and you’re not quite sure what to expect. After nearly four years at Storyblok, moving first to TheyDo and now to Pleo made me grow in a way I didn’t see coming. I learned that onboarding is about a lot more than just jumping into a codebase — it’s about understanding the people, the culture, and how things really get done. Having gone through those onboarding experiences this year, I wanted to share some of my learnings.

Staff engineer onboarding

Build Relationships Early

Whenever I start working with a new system, I get very excited to get my hands on the codebase and open a pull request to learn how the whole collaboration flow works. This instinct to dive into the codebase or architectural diagrams is great for mid-level and even senior positions, but once you go higher into leadership kind of roles, understanding the people and the dynamics matters just as much — if not more. When you go beyond a senior level, you role will require you to work with multiple teams and functions beyond a single team scope. Building early connections provides the context needed to navigate and understand the organization and support the technical contributions that follow.

Networking, networking, networking, networking… You have to be really cognisant of who you’re talking to and make sure that you have connections across multiple teams and multiple groups to leverage those networks.

Katie Sylor-Miller in Staff Engineer by Wil Larson

Building relationships in a new company is about understanding motivations, pressures, and the connections that shape decisions. Talking to various people and roles help you to see which projects are critical to the business, where priorities may clash, and how work actually gets done. You can start by reaching out to colleagues across functions— product managers, data scientists, DevOps, and security teams — and try understanding their day-to-day challenges, which will allow you to bring solutions that genuinely address their pain points.

Small gestures — like joining Slack channels, attending remote meetings, or scheduling coffee chats — might seem trivial, but they lay the groundwork for collaboration and trust. A great way to find the people you should be talking to, is to ask who you should be talking to and what you should be reading as part of your onboarding. Most companies have some sort of onboarding process, but nothing will be as hands-on as the actual input of people who have been at the company for a few years.

But your working relationship and ability to collaborate productively on future endeavors with a specific person can be significantly easier if a relationship was built up beforehand.

Staff Engineer by Wil Larson

Building a stakeholder matrix can be a helpful strategic tool for understanding how to communicate to different people. A stakeholder matrix organizes individuals and teams by their level of impact and interest in your initiatives, providing a quick-reference guide for navigating priorities and relationships. By identifying who holds decision-making authority, who needs to be kept informed, and who can offer critical support or insights, you can streamline communication and focus your efforts where they’ll make the most impact. This matrix isn’t static—update it as you learn more about the organization’s dynamics during your onboarding process. You can see an example of how that might look below:

Stakeholder matrix example

Many leaders, in my experience, tend to fail harder and more often than those who try to learn the organizational ropes and tailor their leadership style to fit the organizational culture.

So don’t just jump into your new role. Take the time to talk with as many people as you can. Figure out how to get connected, how to know things, and how to be in the right rooms. Learn the shadow org chart. Solve some problems, but be humble and assume there were good reasons for previous technical decisions—everything has trade-offs. Figure out how to level up the engineers around you. Understand what’s important.

Cindy Sridharan in The Staff Engineer’s Path

Focus on Learning the Domain

Once you’ve begun to understand the cultural and organizational landscape, it’s time to learn more about the specifics of the industry itself. Understanding market conditions and industry standards are an import factor if you're working at a staff level. Whether your company operates at a small, mid, or enterprise level, knowing the landscape offers insights into scaling, compliance, and customer needs. Explore what competitors are doing, including their tech stacks and approaches to data privacy, security, and scalability.

Learn from your executive and product leadership teams what areas of focus they have for their business strategy and product roadmaps, so you can be prepared to match your technology to them. For example, if your business is in cost-cutting mode, as companies tend to be when revenue is soft or they’re preparing for an IPO, then your technology strategy should match.

Technology Strategy Patterns - Eben Hewitt


Make the Most of Onboarding Sessions
Onboarding sessions are your chance to soak up context. As you listen, write down anything that’s unclear or unfamiliar, whether it’s specific industry jargon, processes, or even competitor names. Then, follow up afterward to connect the dots. For example, if someone mentions regulatory challenges or a big competitor, take some time to dig into those topics.

Spot the Gaps in Your Knowledge
Be honest with yourself — what don’t you know about this industry that you need to know? If you’re in fintech, maybe it’s compliance frameworks like PSD2 or how transaction fees work. If it’s SaaS, maybe it’s understanding churn rates or pricing models. Identify those gaps early and start filling them through reading and asking questions.

Study Documentation
Internal documentation is gold if you know how to use it. Read up on product specs, architecture, and roadmaps, but don’t stop there— pay attention to what’s missing or outdated. That’s often where you’ll find opportunities to contribute early on.

Get Curious About the Competition
Take some time to figure out what your competitors are doing. What tech are they using? How do they handle data privacy, scaling, or customer pain points? Look for patterns or ideas that might apply to your company. Tools like BuiltWith can help with tech insights, and customer reviews on platforms like G2 can reveal where competitors are succeeding — or struggling.

Align with the Company’s Big Picture
Sit down with product leaders to get a sense of where the company is headed. Ask questions like:

  • What’s our biggest challenge right now?

  • What are customers asking for most?

  • Are with in a growth or cost-saving mode?

Connecting this domain expertise with what you’ve learned about the organization’s culture and values ensures that your contributions are contextually grounded and aligned with both business goals and regulatory requirements. Knowing how decisions are made, where potential points of resistance might lie sets you up to deliver better work that supports your company’s mission while navigating industry-specific complexities.

Understand Your Scope and Expectations

Setting up clear communication with your manager and stakeholders early on is an important part for defining your role and shaping a shared understanding of success. Clarify the scope of your work, areas where you have decision-making authority, and how your performance will be evaluated. Knowing where you’re expected to lead, support, or collaborate will guide your day-to-day focus and help you prioritize effectively.

Clarify Responsibilities and Scope
Determine the domain or teams you’ll focus on and whether your impact will center on a single architectural area or span multiple teams and technologies. It’s also valuable to understand if your primary responsibility is supporting initiatives within your manager’s domain or tackling cross-organizational challenges.

Establish Decision-Making Authority
Gain clarity on the decisions you’re empowered to make independently versus those that require collaboration. This may involve familiarizing yourself with both formal decision-making processes and informal influence networks.

Your manager’s and colleagues’ expectations may differ wildly from yours on what a staff engineer is, what authority you have to make decisions, and myriad other big questions. If you’re joining a company as a staff engineer, it’s best to get all of this straightened out up front.

The Staff Engineer’s Path by Tanya Reilly

Align on specific goals and measurable outcomes so that both you and your team have a shared understanding of success. This clarity from the outset reduces ambiguity, minimizes the risk of misunderstandings, and sets a strong foundation for meaningful contributions.

Embrace the Learning Curve

Starting a new role means adjusting to new tools, workflows, and dynamics, even if you have years of experience. Acknowledge upfront that there will be things you don’t know, and build a practical approach to closing those gaps. Begin by identifying key areas where you need to get up to speed—whether it’s technical details, processes, or team-specific practices.

Don’t hesitate to reach out to colleagues for context or advice on specific areas. Ask clear, pointed questions to fill in knowledge gaps and understand the reasoning behind decisions, as this often uncovers valuable insights that aren’t in formal documentation.

Break Down Your Learning Areas
Start by listing the areas where you need to study some more. This might include:

  • Technical Details: Learn the codebase, infrastructure, and tools.

  • Processes: Understand team workflows, release cycles, and incident management.

  • Domain Knowledge: Dive into industry-specific concepts and regulations.

    A simple table or Kanban board (Trello odr Notion work great) can help you track these areas as you go, here is an example in Obsidian:

Create Visual Aids
As you learn, make it visual. Diagrams, flowcharts, or quick-reference guides can help you connect the dots. For instance:

  • Map out how different services interact in a architecture diagram

  • Create a timeline of the development cycle to understand key milestones.

  • Use mind maps to track domain-specific knowledge or acronyms.

Tools like Eraser or Excalidraw are great for these visuals.

Regular Check-ins with Your Manager
Use weekly 1:1s to validate your focus. Ask:

  • “Am I prioritizing the right areas?”

  • “What’s the most important thing I should be learning right now?

When you move into a new role, there will inevitably be skills that you don’t have yet, or domain knowledge that will be new to you. You may find that you’re learning from the junior engineers you work with. (This is a good thing!) Here is where your technical knowledge provides a foundation. While you might not recognize the specifics of the problems in this new domain, your general experience should help you recognize their shapes. You should be able to pattern-match what you’re encountering to something else you recognize, so you’re not completely at sea.

The Staff Engineer’s Path

As you work through the onboarding process, make a habit of mapping out what you’re learning — create diagrams, notes, or even quick-reference guides that help you visualize how pieces of the system fit together. Regularly check in with your manager to confirm you’re focusing on the right priorities and building understanding in key areas. By keeping a practical and systematic approach to learning, you can steadily build the knowledge and confidence needed to make informed decisions and contribute effectively.

Deliver Value Early On

Contributing tangible value in your first weeks is one of the best ways to build credibility and show your commitment to the team’s success. Focus on identifying quick wins — small but impactful contributions that can demonstrate your initiative. Often, these opportunities arise in documentation: write down what you’re learning as you onboard, whether it’s workflows, troubleshooting steps, or the reasoning behind certain architectural choices. This not only solidifies your own understanding but also creates resources that can ease onboarding for future team members.

Another high-impact way to contribute early is to broadcast your findings. Share insights, observations, or improvements with the team through short write-ups or Slack updates. Regularly broadcasting your progress keeps stakeholders in the loop and shows initiative. For example, after wrapping up a documentation update or bug fix, consider presenting your findings in a broadcast document to highlight the impact and share the learnings with other team members. These early contributions, especially around documentation and visibility, build momentum and demonstrate your focus on both immediate needs and long-term team efficiency.

Build Trust Through Collaboration
Acknowledge that joining a team can disrupt dynamics. There's often anxiety that a new member might unintentionally introduce new issues in the system or take on someone else’s pet project. Address this proactively by:

  • Seeking feedback early. Example: "I’m proposing X for this documentation update — does this align with how the team works?"

  • Celebrating others’ contributions. Example: "This part of the architecture is so clean — it really helped me understand the system. Kudos to whoever designed it!"

There’s a lot of natural anxiety and insecurity that the new person won’t build your Lego tower in the right way, or that they’ll get to take all the fun or important Legos, or that if they take over the part of the Lego tower you were building, then there won’t be any Legos left for you. But at a scaling company, giving away responsibility—giving away the part of the Lego tower you started building—is the only way to move on to building bigger and better things.

The Staff Engineer's Path

Conclusion

If there’s one thing I’ve learned in the last year, it’s this: take the time to map out the context you are working in and connect it to your own understanding. Build relationships, get to know the business, and stay focused on filling your knowledge gaps. Delivering value early is also important — whether that’s updating documentation, fixing small bugs, or sharing insights. These small wins matter and show your team you’re not just here to be paid at the end of the month — you’re here to help and to make deeper impact.

A friend at a huge company once compared his career journey to playing Diablo, a classic role-playing video game. “I fight all the monsters and clear the dungeon,” he said, “and eventually I collect enough experience points to go up a level. But then…I just start again in a new dungeon and the monsters have also gone up a level! What’s the point?!”

The Staff Engineer's Path

The key is to stay curious, communicate openly, and prioritize learning the things that matter most. With that approach, you’ll set a strong foundation for making an impact.

More articles