A Staff Engineer role is the beginning of an engineering leadership role where you lead without direct management authority. Staff Software Engineers are commonly expected to act as an enabler for at least two teams and think about bigger problems across a team boundary. A common setup is to assign a staff engineer a portfolio of teams to influence as an Architect. Some companies with very complex problems may assign Staff Engineers to be Solvers. Read more about the different Staff Engineer Archetypes
As a Staff Software Engineer, you will be expected to communicate across teams and share designs / best practices. As a result, you will need to learn how to:
For more details, check out this article about Documentation in Software Architecture
Learning how your organization works will inform your outlook on:
Because you will be working across multiple teams, it's less likely that you will be following the standard 1-week / 2-week sprints like you did when you were a Software Engineer in the team.
Instead, you will be most likely be managing your work via some kind of kanban board. Why kanban? Because:
Although you are not strictly following the sprints, it is still very important to stay close to the team. Read this article on The Agile Manifesto: A Software Architect's Perspective.
As you are straddling between multiple teams, you would usually have less control over what the team does as compared to the Engineering Lead. Use the trust you have built with many engineers over your time in the company to help you pitch an idea.
If you are new to a company, then you would need to build the trust from scratch. You should not use your title to drive people towards action. That never works well in the long term. Instead, ask a lot of questions and have direct conversations with your engineers to learn about the problems they face.
Once you have learnt their problems, it is a lot easier to come up with a solution that directly addresses their problems and make their lives easier. This book about Driving Technical Change talks about this topic and a lot more.
A big part of your role is to discover new ideas to solve problems. Most of the time, you have a hypothesis and you can test that hypothesis by creating proof-of-concepts (POCs). From this article about How to run PoCs
The goal of a Proof Of Concept is not to deliver working functionality. Rather, it is a way to test if the project is technically feasible. In a more general description, you could also say that the goal of Proof of Concept is to de-risk the project by implementing all the risky technologies and architectures that the developer doesn’t know yet if it’s possible to implement or not.
These POCs go a long way in helping you as a staff engineer:
Documentation should be done for your POC so that others can easily refer to a single document, understand the analysis and conclusions.