I will add one more

## Compassion
The ability to Sympathize with others and  understand where they are coming from becomes increasingly important as you progress in your career

- Use compassion to understand the need of your teammates
   - Know them not just in work settings but take your time to understand their interest, passion and career goals.
   - This gives you an edge when collaborating with them since you know "what drives them".

- Use  compassion to understand the priorities of your managers/directors
  - Managers (especially frontline ones) have a hard job. They are basically sitting in meetings and have to deal with all the distractions. Sympathize with that and see how you can make their jobs easier.
  - This gives you an edge to really understand what are the most important things for you to deliver.
 

- Use compassion to understand the priorities of other teams
  - Things that are important to you and your team might not be a priority for others. Dig in and understand what their priorities are and see how you might be able to help
  - This gives you an edge to achieve alignment when there is a conflict.

Staff Software Engineer @ DoorDash, ex-FB, ex-Klaviyo

Seed Zeng

Lots of good suggestions on this read already. I will just add 3 quick points

1. 100% agree you should have an agenda beforehand for any meeting (even 1:1s). On your meeting Agenda, you should clearly state what is the goal for this meeting. 

2. It's not disrespectful to interrupt a person that's clearly rambling. If the you feel the discussion is not related to the agenda / goal you trying to achieve, forcefully but politely point out we should stick to the agenda. You can do this by saying
    - that's a good discussion we should have outside of this meeting. let me document it and let's table that for now

3. I often DM the person and check with them that they do not feel offended. As you said, most of the mare not intentionally hijacking the meeting.

Alex already answered this really well. I will just add one extra point

You need to take a step back and better define what you mean by "do well".
If the goal is to get good ratings and become a productive, reliable engineer on the team, absolutely (especially in a health working environment)

If your ambition is to learn as much as you can, quickly become a domain expert in some area and establish yourself as the expert of several areas, then no.

Be honest with your ambitions and choose accordingly.

This is a good question but also very generic. 
It really depends on the level, the context and the priorities of team.
The expectations & areas of focus are very different for different levels. 

If I must generalize,  a "high performer" are able to do two things compared to a "low performer"
- be self sufficient and able to drive large changes on her/his own. 
- be able to share their learnings with others and increase the team efficiency as a whole.

Yeah, they are the worst. Wish we can just get rid of them! JK :) 

I do not care how smart / talented you are, you will always encounter someone seems to be 2x better than you in any regard. Here is how you approach it with a "winner's mindset"
- **leverage the fear**
  - It's healthy to realize your shortfalls. It's a sign of confidence not a sign of weakness. 
  - The core thing is you have to change your mindset to realize that admitting others are better than you in some areas does NOT equal to your incompetence. 
  - You should start to relish the fact you identified areas for improvement. Leverage the fear of falling behind and make ameliorations one step at a time.

- **learn from them**
  - What makes them so efficient. Do they have a framework of approaching things? Do they have unique methodologies? What's the magic behind their efficiencies?
  - You are on the same team with them. That's a great opportunity to learn from them.
  - They are not threats to you but resources for you to better yourself. I would set up regular 1-1s with them and try to learn 1-2 things from each of them.

- **find your own lane(s)**
  - There is a reason why you are on a team with talented people. You are talented as well :) 
  - Give yourself time and space to find the domain(s) you can become experts in. When you have learnings, do not hesitate to share with others. They can also learn from you.

Alex already made some great suggestions especially regarding code quality. I would add  a few more
- document your findings and any learnings. Share them with your team. This is a very good way to build a reputation for yourself. Most importantly, a vital way to promote a collaborative culture on your team.
- For any complicated design decision you are making, write your though process down in a doc. Take a step back to think deeply about the problem first before you start writing code. This is a very important mindset change from junior to senior. You also can use this doc in two ways
   -  present this doc as a RFC if you want more opinions.
   -  point to this doc when asked about why you made this design decision.
- leave anything you touch better. This could be 
  -  something in code.
  - a wiki doc you read.
  - a onboarding process that you find annoying
- we are all humans. spend some time getting to know other people (not just senior SWEs) on your team. Like you said, it's a small team, it's very important to know them in the context out of work. Build a deeper connection and it will make work more fun and efficient. Some of my closed friends right now are the ones I made during I worked at Klaviyo (my first startup).

I think others already made a lots of good points. I will just add one.

Let us be clear, you are `replicating that deep knowledge` as we speak. A big part ramping up is asking for help to unblock yourself. Leverage the fact that you are new and earlier in your career to ask pertinent questions.  Senior engineers expect you to ask questions especially during onboarding.

You should also do two things while asking those questions 
- make sure you do not ask the same question twice.
- document your findings & learnings and share with the team.

Late to the party but this is an important question since we will all face it at some point.
Alex already made some good points here.

IMO, besides ramping up & demonstrating your skills are only part of the equation. You also need to build a map of knowledge about your team, your org, the company. Eventually, you want to be able to answer "what are the problems I should solve / what domains i should become expert in" in 6 months. 

Here is a framework I stole from the CTO of FB (Boz) 

## From Boz (NOT me)
— Written by Boz @ FB

Several times in my career, I’ve joined a team whose work was already well under way, where I had a massive knowledge deficit, and didn’t have pre-existing relationships. None of those excuses relieved me from the pressure I felt to establish myself and contribute. Over time, I realized that the natural instinct to push for early impact leads many incoming leaders into challenging relationships as they expose their knowledge deficit and waste time. So, I developed an algorithm that has helped me ramp up quickly — and in several cases — have an impact in a relatively short period of time, while minimizing collateral damage.The first step is to find someone on the team and ask for 30 minutes with them. In that meeting you have a simple agenda:

- For the first 25 minutes: ask them to tell you everything they think you should know. Take copious notes. Only stop them to ask about things you don’t understand. Always stop them to ask about things you don’t understand.
    - The sum of the answers from the first 25 mins will not give you a complete picture of the team's work. That will take months to develop. But they will give you a framework for integrating new information more quickly, which will speed up how fast you ramp. It will also heavily over index on the areas of work under active discussion, which will help you dive in productively to the most critical discussions immediately.
    
    The nature of what people choose to discuss is a very valuable signal about the problems the team face, as it may be about the work, the organization, or process. Finally, it will give you a sense of the language and terminology that can very often be a barrier to working smoothly with teams.
    
- For the next 3 minutes: ask about the biggest challenges the team has right now.
    - The answers from the second question give you a cheat sheet on how to impress the team with early positive impact. Some of the things you'll hear will take time to fix, such as “we need a bigger team” or “our infrastructure isn’t scaling.” Those are important and it will be good for the team to hear you internalize those challenges. But a surprising number of the issues you'll hear repeatedly will be things you can easily help with, like “we waste a bunch of time in meetings every week” or “we need a dedicated conference room.” I start with the latter as quickly as I can because those are the types of things teams often neglect to prioritize, in spite of a compounding negative impact on progress.
- In the final 2 minutes: ask who else you should talk to. Write down every name they give you.

Repeat the above process for every name you're given. Don’t stop until there are no new names.

Without too much context, I think you can do a few things to start with

- understand why the planning is so long?
   - too many dependencies?
   - lack of domain experts?
   -  hard to size?
   -  hard to get alignment?
- Plan for longer? there are times it takes long time to plan out a long term roadmap. From sprints to sprint, you really should not re-plan lots of milestones.
- are there lots of disruptions where your requirements to deliver changes?
  - then that's a different set of problems to address.

In my experience, what works best for me is to block off times on work my calendar dedicated for
- workout
- cooking
- winding down
It acts both as a reminder to myself and also a note to co-workers.

I also encourage you to take a step back what is the problem you are trying to solve here. WLB is a tricky word because it's you that need to find the balance. 9 - 5 is not necessarily what you should aim for based on your circumstance. 

Sounds like you are in a flow state working on something you are passionate about. That's a good thing. If it's impacting your sleep because of you cannot turn off your mind soon enough, work on that.

Alex's answer is awesome and comprehensive already.

If i would add one more point is that, for SWE1 -> SWE2, you can heavily leverage your manager to give you clear guidance. 
- Be direct to your manager that your goal is to get promoted soon and ask how you can function at a SWE2 level.
-  In your 1:1s, frequently check in with your manager to see if you are on track.

>how do I take the behaviors my company has associated with each role (below) and make that more concrete for a growth plan

First of all, I want to stress that one of the reasons people want to work at a startup is the ability to own large scopes no matter what ur current level is.
What really helped me grow faster compared to lots of my peers is this mindset 
```
show up, own the hardest problem from the get go. It's ok to fail. 
As a matter of fact, you should frequently fail. 
If you are not, it means you are not challenging yourself enough.
```

Now to your specific question.
I think on a tactical front, the rubric you shared already made everything pretty clear
* Technical Skill
    * become an expert in some areas that matter to your company
* Getting Stuff Done
    * Implement stuff & build lots of features
* Impact
    * lead larger projects and take them across the finish line
* Communication & Leadership
    * help others
    * communicate ur progress & unblock yourself when needed

The transition from SWE I -> SWE II (E3 -> E4) is very straightforward. It's basically you doing more stuff better and faster. 

Leverage your manager to make sure you are on track and you should get there relatively fast.

Do you plan to get a PHD?
If you are considering Masters, they do not provide you with too much specialization. 

In general, going back to school does not really propel you in your careers unless it's a very niche area. Without enough context, I would say you should consider start learning things in robotics, perception, localization or AI by taking on projects.

I also encourage you to think about longer term vision. Do you want to become the best researcher in your field or you mostly want to leverage ideas from researches and build awesome products.

```how do I evaluate the business impact a project has and prioritize all the different things on my plate accordingly```

In a small startup, this should be quite easy. I used the following filters
- can the business function without the success of a project 
- what's customer visible impact if we finish this 
- how fast do i need to finish this and what difference does it make

```how do I make sure that the scope of projects are matching my level```

You are in a seed stage startup. You should leverage that. Go to leadership and be upfront. You can directly ask them whether you are driving useful projects for the business.

source: I was an early employee at a small startup

At a higher/abstract level, you should always take a step back to reflect what you can do to make the company more successful. What are the things you think you can contribute/lead to help improve the product, the process and the productivity of the team. In an ideal world, promotion is an after thought. Focus on learning and making the product better. Promotion will come naturally.


However, we do not live in an ideal world, so let's move onto the more tactical level.
The paths to Staff engineers can vary. However staff engineers in general are expected to excel in following things
- can function as a very strong IC 
- help the team to function more productively through mentorship, knowledge sharing and directional guidance.
- have org-wide impact via working on xfn initiative, being a thought leader and creating scopes for other engineers.

Based on those expectations, you can reflect upon what are the gaps in your current behavior. You should also work with managers and ask him/her to help closing those gaps.

Specifically to your question, a small pod in a startup does not prevent you from finding the path to grow to staff. On the contrary, it gives you the opportunity to demonstrate 
- how you can be efficient and function well under limited resources.
- how you can lead the team to efficiently interface with other teams.
- how identify/create opportunities/scopes for you and your teammates.

To be a staff, it's no about grabbing a big project for yourself and optimize for the maximum impact possible. It's about becoming the 10x engineers that make the team, org and the company function better.

Good luck :)

It's a little hard to answer this one. Clarify the following first
* what exactly is the level you are trying to get promoted to
* <as my previous team was sometime back, what all should I do to get maximum leverage for a promotion> -> what do you mean by this?