Congratulations on your promotion to Staff level! Thank you for sharing these valuable insights, looking forward to more of this sharing.
I agree that the transition from Senior to Staff is a significant behavioral shift that requires a new way of thinking.
Senior roles are typically execution-focused, whereas Staff roles emphasize vision, strategy, and deep technical strength. While a Senior Engineer's scope is often provided, a Staff Engineer must proactively define their own, which is one of the key areas discussed in this post.
Thank you so much, Roger! Totally agreed with your additions. We'll touch on more of the principles that help with operating at Staff from an influence side in the next article too
Congrats, Jordan, that's amazing. Just curious, since you work on the Frontend, is your idea/scope always on "how can we improve frontend"? Or, since the frontend is close to UI/customer, do you also come up with product ideas as staff?
Thanks a lot, Anish! I'm on Web Platform, so it's actually more about how we can enable frontend engineers to ship product code faster. But if I was more of a product staff engineer, I definitely would be coming up with product ideas regularly
Awesome article. Going to apply to my work immediately. How do you, as a senior engineer, perform these behaviors successfully when you have either another senior on the team who’s been at the company much longer/tester/BA that take a different stance on every area you find as an improvement? The process goes in this way most of the time. A team member disagrees with your fix, the other team members join in with whatever that team member recommended not even giving what you mentioned a second thought. The other case is that they decide to put your fix on the backlog and then every-time they come up with a fix, the other team members agree and it gets worked on right away.
Is the issue that the culture of the team is one where everyone needs to agree on what should be worked on before it’s done? Then there’s certain devs from other teams that your devs agree with on everything they decide should be fixed and worked on.
Why do other devs get this privilege over some leaving the latter to be just cogs.
Is it an unwritten rule where you can’t start your path to staff unless the team members vote you in?
What do you do when you start your path to staff as I have and your teammates undermine you, you are the defined lead of the team and your teammate precedes to do your job such as running refinement as the ba/pm told the tech lead, myself, to do. Then in the meeting I start to run refinement where then the teammate asks if they can share their screen giving you a dirty look and then preceding to run refinement. Obviously I’m not going to be petty and preceded to participate in the teammate now running refinement.
What do you do when these just aren’t one off situations and at every one of the actions you mentioned in your five principles, the teammate or teammates essentially block you preceding. You precede to talk with the teammates about roles which seems to go well and you agree but then their behavior doesn’t change. You think about going to your manager. Not had much success there in the past. Hr? Same result.
The second these team members see an opening to derail they do it and it never stops.
How do you maneuver difficult situations like this in the path to staff? Let’s be honest here real situations like the one I’ve recently experienced over 6 months are very common leaving the non-offenders passive, submissive cogs to their dominating teammates, on the other end just leaving the team for another to start their path to staff over again, even worse up and quitting not able to handle the difficult situations, losing their cool and getting fired, staying on the team to have the toxicity slowly wear you down unless uber resilient.
Fortunately I haven’t fallen into one of the areas I’ve described. That’s not my point here though. I’ve read many books at recommendation from mentors in high tech or manger leader positions to respond to the silence or violence. That said no amount of skill or talent is going to get you to staff regardless of how deserving if your manager asks your teammates ( ones I’ve described above ) if they’d be willing to have you as the staff/lead and they say no, making up reasons or exaggerating circumstances.
Usually ends up with your manager blaming you for not “building the relationship,” enough with the team even though you consistently attempted to doing everything in your knowledge, skillset, ability with help from many mentors saying you’re doing the right thing.
Hey Joel, I appreciate the kind words about the article and question! Your question has many parts to it, so I don't know if I could effectively answer it in a single comment, but I'll do my best to provide direct and actionable feedback for you.
The root of your question seems to boil down to "do you need relationships to reach Staff?" and in my experience it has seemed like the answer is > 90% of the time, yes. A common trait I've seen among Staff engineers is they are well-liked AND technically strong. And for good reason. Their role requires them to consistently get alignment across areas that require relationships. This is why it can even be difficult for newly joined Staff engineers to perform well if they don't build relationships quickly with the right people.
Congratulations on your promotion to Staff level! Thank you for sharing these valuable insights, looking forward to more of this sharing.
I agree that the transition from Senior to Staff is a significant behavioral shift that requires a new way of thinking.
Senior roles are typically execution-focused, whereas Staff roles emphasize vision, strategy, and deep technical strength. While a Senior Engineer's scope is often provided, a Staff Engineer must proactively define their own, which is one of the key areas discussed in this post.
Thank you so much, Roger! Totally agreed with your additions. We'll touch on more of the principles that help with operating at Staff from an influence side in the next article too
This summarizes the article pretty well.
Congrats on the promotion! This is really valuable for my current situation!
Thanks a lot, Bruno. That's awesome to hear!
This was really useful. Thank you! And Congratulations!
Thanks, Edmond!
Thank you, Jordan, very beneficial.
Of course and thanks for your comment!
Congratulations and thank you for this insight
Thanks a lot, Bernard!
Congrats, Jordan, that's amazing. Just curious, since you work on the Frontend, is your idea/scope always on "how can we improve frontend"? Or, since the frontend is close to UI/customer, do you also come up with product ideas as staff?
Thanks a lot, Anish! I'm on Web Platform, so it's actually more about how we can enable frontend engineers to ship product code faster. But if I was more of a product staff engineer, I definitely would be coming up with product ideas regularly
Ahhh, I see. Thank you.
Congrats on the promo!
Thanks so much, Leo!
Congratulations on your promotion to Staff Engineer, Jordan. Looking forward to learning more.
Thanks a lot, Jeffrey!
Congrats on your promotion. Great article!!
Thanks, Nishaz! I really appreciate it
Awesome article. Going to apply to my work immediately. How do you, as a senior engineer, perform these behaviors successfully when you have either another senior on the team who’s been at the company much longer/tester/BA that take a different stance on every area you find as an improvement? The process goes in this way most of the time. A team member disagrees with your fix, the other team members join in with whatever that team member recommended not even giving what you mentioned a second thought. The other case is that they decide to put your fix on the backlog and then every-time they come up with a fix, the other team members agree and it gets worked on right away.
Is the issue that the culture of the team is one where everyone needs to agree on what should be worked on before it’s done? Then there’s certain devs from other teams that your devs agree with on everything they decide should be fixed and worked on.
Why do other devs get this privilege over some leaving the latter to be just cogs.
Is it an unwritten rule where you can’t start your path to staff unless the team members vote you in?
What do you do when you start your path to staff as I have and your teammates undermine you, you are the defined lead of the team and your teammate precedes to do your job such as running refinement as the ba/pm told the tech lead, myself, to do. Then in the meeting I start to run refinement where then the teammate asks if they can share their screen giving you a dirty look and then preceding to run refinement. Obviously I’m not going to be petty and preceded to participate in the teammate now running refinement.
What do you do when these just aren’t one off situations and at every one of the actions you mentioned in your five principles, the teammate or teammates essentially block you preceding. You precede to talk with the teammates about roles which seems to go well and you agree but then their behavior doesn’t change. You think about going to your manager. Not had much success there in the past. Hr? Same result.
The second these team members see an opening to derail they do it and it never stops.
How do you maneuver difficult situations like this in the path to staff? Let’s be honest here real situations like the one I’ve recently experienced over 6 months are very common leaving the non-offenders passive, submissive cogs to their dominating teammates, on the other end just leaving the team for another to start their path to staff over again, even worse up and quitting not able to handle the difficult situations, losing their cool and getting fired, staying on the team to have the toxicity slowly wear you down unless uber resilient.
Fortunately I haven’t fallen into one of the areas I’ve described. That’s not my point here though. I’ve read many books at recommendation from mentors in high tech or manger leader positions to respond to the silence or violence. That said no amount of skill or talent is going to get you to staff regardless of how deserving if your manager asks your teammates ( ones I’ve described above ) if they’d be willing to have you as the staff/lead and they say no, making up reasons or exaggerating circumstances.
Usually ends up with your manager blaming you for not “building the relationship,” enough with the team even though you consistently attempted to doing everything in your knowledge, skillset, ability with help from many mentors saying you’re doing the right thing.
What do you think?
Hey Joel, I appreciate the kind words about the article and question! Your question has many parts to it, so I don't know if I could effectively answer it in a single comment, but I'll do my best to provide direct and actionable feedback for you.
The root of your question seems to boil down to "do you need relationships to reach Staff?" and in my experience it has seemed like the answer is > 90% of the time, yes. A common trait I've seen among Staff engineers is they are well-liked AND technically strong. And for good reason. Their role requires them to consistently get alignment across areas that require relationships. This is why it can even be difficult for newly joined Staff engineers to perform well if they don't build relationships quickly with the right people.
For some resources on building the communication and influence, I'd recommend (1) my next article, which will touch on this, (2) if you are a paid subscriber, check the "Communication and Influence" learning track: https://read.highgrowthengineer.com/p/learning-tracks and (3) Sidwyn Koh's recent article also gives some good advice to help with the situations you mentioned: https://www.pathtostaff.com/p/an-engineers-guide-to-influence-part