What are some hurdles that senior engineers face when getting promoted to staff engineer?

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.

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).

"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?

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.

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 :-)

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?

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).