What are some hurdles that senior engineers face when getting promoted to staff engineer?
I see some senior engineers getting promoted to staff within 2 years. Whereas other senior engineers take 5-7+ years.
What are some hurdles that senior engineers face when getting promoted to staff engineer? How to watch out for and avoid these hurdles to get promoted within 2 years?
What’s the biggest skill to start mastering or how to set yourself up for success at an early stage to make this promotion faster?
Is it easier to get this promotion in big tech or a startup?
Does changing teams or orgs or companies delay this promotion?
Discussion
(8 comments)- 2
12 days agoEngineer @ RobinhoodI got pretty close, so I think I can give a viewpoint on the hurdle(s). The main one for me is letting go if being directly responsible. As a senior engineer, I saw a lot of growth and realized impact when I was directly leading projects. But the dynamic (espically for what management wants) is shifting more towards having others lead/own projects and how I'm able to support them.
This is unfortunately the point in my career where I can no longer "solo carry" my growth: I'm dependent on others, and I have no direct control over others. Unlike my manager, I do not have a title that implicitly has the power of "do what I say or you're fired". Instead, I've been shifting towards:
- Building relationships
- Understanding the relationships I have with others surrounding my work
- Being able to evaluate the strengths and weaknesses of people (especially engineers)
Relationships take a long time, so these skills around them do as well. It's very hard to speed run these skills: if you're trying to force yourself as a lead, people will often have some frustration because you're trying too hard to be at a skill level you're not (and it's fairly obvious too). There are so many variables out of control, but there are variables that can be somewhat controlled to reduce the time.
- Tenure in the company/team (ideally both). The longer your tenure is, the more time you've had to understand the people, the culture, and the technology. If your tenure is longer than everyone else around you, people will implicitly bias to you as a "subject matter expert".
- Ownership. Long tenure does mean you have more opportunities to understand the company more than others, but you still have to put in effort to pursue those opportunities. Proactively looking to own things (be the "go to" person) will put you in a position to understanding systems more deeply (if you don't understand it well enough, people will stop going to you. Not a good thing for a "go to" person).
- Individual skill. You cannot grow if you're the bottleneck of the team (in terms of average baseline of code quality and speed). If you are the top in a few categories, people will see/assume that you're skilled and implicit will gravitate towards you.
- 012 days agoMid-level Software Engineer [OP]Taro Community
That's an interesting insight. This is my understanding. Please correct me if I'm wrong. Basically, we need to have ownership of the project and make sure the project succeeds. But we shouldn't execute the project ourselves and outsource it to the team. When a team member gets stuck with an issue, we need to hop in to make sure we remove the hurdles for the team member.
- 112 days agoEngineer @ Robinhood
It's a level higher than that for Staff. You don't own the project: you own the team (a collection of people and projects). If your teammate gets stuck, it should be on them to get themselves unstuck. You are there to guide them how to get unstuck more efficiently in the long run. You can help them get unstuck here and there witthout too much scrutiny, but if you do it too much that wouldn't reflect well on you (this is okay as a senior though).
- 012 days agoMid-level Software Engineer [OP]Taro Community
"Tenure in the company/team (ideally both)"
Does this mean it is hard to job-hop from senior engineer to staff engineer at another company?
We may not have fully developed a good bond with the new team and may not have mastered the codebase as much as them. So, they might potentially resist our decisions/leadership?
In your opinion, what would be a good time frame to build the relationships and skillset in the new company to become a staff engineer? - 112 days agoEngineer @ Robinhood
If you job hop, you need to build relationships all over again (regardless of level). Relationships generally take years: I'd say best case, it takes a 1-2 years to build the relationships. And there's influencing impact over those relationships, which takes another 1-2 years. So that brings the range to 2 years minimum best case. If you try to jump the gun and try to influence without any strong relationships, people will just ignore you best case or try to get you fired worst case.
It's very hard to master the complexities of relationships without a strong foundation of technical (mainly coding) and non-technical (mainly driving xfn discussions to getting people to agree on something). If your goal is to be the "staff" (in quotes because in the end a title is just an arbritrary string) engineer that's balancing technical, business, and people needs, focus on the perfecting the basics first. I wouldn't trust a chef who can't consistently boil an egg to consistently cook a Beef Wellington, and I wouldn't trust someone trying to be a tech lead when they're struggling to push out code on time.
- 012 days agoMid-level Software Engineer [OP]Taro Community
Oh my god! If every job hop puts me back 2 years in my career, then I'm basically going to have to stay in this company for a long long time then :-)
- 012 days agoMid-level Software Engineer [OP]Taro Community
Spending 2 years on onboarding to gain the team's trust and exert influence in a new team seems kinda long. To gain the team's trust faster, would it help to maintain a good online presence by frequently writing blog posts, linkedin posts, doing side projects, and maintaining a green GitHub profile?
- 011 days agoEngineer @ Robinhood
That's more like influencing & people don't generally care about that. People at work care about 2 things for someone:
- Does this individual have a personality I'm comfortable working with?
- Is the person sufficiently compotent in my day-to-day interactions?
The nature of how most relationships are built are through 1:1 interactions. A company is a collection of people in the end, so the more number of good relationships you have the more potential you have to influence over the broader company.
I've tried to jump straight to staff+ behaviors earlier in my career, but I was never able to accomplish anything meaningful in my career. I didn't have the strong technical fundamentals that clearly set me apart from my peers (making it harder for me to drive action just by myself & making it harder for engineers to implicitly trust me), and I didn't have an understanding of the foundations of a good relationship (making it frustrating when people were okay with things that I was pushing, but they never really did much else).
If you want to take the most consistent next steps in your career:
- Get good at your current job. Make it clear that some aspect of your technical skills outstrips your peers (coding speed, code quality, company-level technical domain knowledge, general technical expertise).
- Be kind and helpful to other people (both technical and non-technical. Good relationships are built from consistent stream of positive interactions, and beinging helpful and kind are the most straightforward ways to set relationships up on a positive note (especially when you don't know who you're going to frequently interact with in the future).
