You have a problem with authority, Mr. Anderson
This post is tightly coupled to my own limited experience of working in a very nebulous role, in one of the teams of a fairly large IT company. That said, there neither seems to be a general consensus of what a staff engineer role entails. Usually, people will outline collaboration between different teams, technical excellence and organizational skills.
Before ever being a staff, I was first and foremost cynical about IT and climbing the corporate ladder (and life in general), and the role simply solidified my views on it. But, if nothing else, I would like to think it has primed me for writing this blog post by dishing out a myriad of Confluence articles.
Becoming a staff engineer
This will widely depend on the team you're in and the people that surround you. There is no simple way to normalize skillset and effort across different teams with different responsibilities operating inside a different people dynamic. In some teams, you might have someone to look up to, who does this role really well (which was my experience), and little by little you can embody and replicate whatever that person does. In other teams, you might invest all you've got and adopt the role perfectly, and there still may not be a path open to you for various organizational reasons.
Hierarchy and authority
Some people view company hierarchy as a commandment and pull rank any chance they get. Staff role is a breeding ground for this in my opinion. It is the proverbial team lead role, but we're all afraid to say it, even though we all tacitly understand it and respond to it.
In my experience, staff is there to help engineering manager and alleviate some of the intra-team communication pressure. However, a person is still designated for this role and hierarchy is introduced inside the team. I don't think there's any need for this. Coworker from a different team might ask me for a feature on Slack and my first instinct will be involving and consulting my team. I will never decide on my own, or withhold information from them, let alone do something behind their back. So, in my opinion, there is a hierarchy that doesn't serve anyone, it just adds a communication layer. I can only imagine how this might get abused by someone willing to pull rank and exercise authority. And it sucks.
Ambition
IT companies reward (maybe even incentivize) blind ambition. And a lot of programmers are willing to play that game. This becomes very evident when you transition from SSE to staff. It's not something that's a given and you have to have a certain skillset under your belt. Being ambitious might mean going against your team for your own interest. It means getting involved into problems that could circumvent your team but getting involved means added praise, so the team gets involved by proxy.
Inertia
To contradict my previous paragraph, in large companies, promotion to a staff role might also happen out of inertia or simply because someone needs to fill that role and no one inside the team is adequate enough. You just pick someone who might do the least amount of damage and call it a day, leaving everyone else to compensate for it.
Being a natural leader
Throughout my career, I met people who are natural leaders - able to read the room, anticipate the situation and find the right words. These are precisely the people that perform the staff engineer role. But, in my opinion, the team would gravitate to them, even without the role being officially recognized. I think this would be a much more natural relationship. Does that even matter?
Does it even matter?
No, and that is the worst and best argument I could make. It doesn't matter. On paper, it is different, and you're a staff, but if you're a good staff, this won't affect the team dynamics that brought you there. So does it even make sense to formally recognize the role?
Recognizing your limits
Power corrupts. Even if it is very scoped and limited to writing polite feature requests. You might think you have influence and that you are somehow better and different than your colleagues (cue the Matrix quote). If you're not a reflective person and someone who actively tries to understand why they do the things they do, and what are your teammates' positions and opinions, this might psychonuke you. Granted, most of the staffs I work with are normal and reasonable people, with an ambition and pride worn down by years of trying to change things that can never change.
Closing words
Writing this, I've had many of my colleagues in mind, and the situations I have difficulties with, day to day. As much as it is about being a (natural) leader, it is also about learning and being willing to recognize your flaws. It's hard being wrong when you're troubleshooting a critical error, it's hard to recognize that your colleague has an excellent point that completely annihilates your argument.
More than anything else, to me, it is about being open, curious and supportive. Some of the mistakes I outlined, I also made myself, and will likely make again.
But, at the end of the day, I am happy when I see someone grow and learn and adapt, and being able to vouch for them with even a modicum of leverage the hierarchy gets me, is my favorite way of being a staff engineer.