TLDR
- Staff engineering roles are ambiguous by definition. It’s up to you to discover and decide what your role is and what it means for you.
- You’re probably not a manager, but you’re in a leadership role.
- You’re also in a role that requires technical judgment and solid technical experience.
- Be clear about your scope: your area of responsibility and influence.
- Your time is finite. Be deliberate about choosing a primary focus that’s important and that isn’t wasting your skills.
- Align with your management chain. Discuss what you think your job is, see what your manager thinks it is, understand what’s valued and what’s actually useful, and set expectations explicitly. Not all companies need all shapes of staff engineers.
- Your job will be a weird shape sometimes, and that’s OK.
Three pillars of staff engineer role
- Big picture thinking. It means seeing beyond the immediate details and understanding the context that you are working in. Thinking beyond the current time.
- Execution. Projects will become messier and more ambiguous. They request more from you to succeed with them.
- Leveling up. You have more responsibility for raising the standards and skills of the engineers withing you orbit by intentional influence (teaching, mentoring) and accidental influence (being a role model).
Technical knowledge and experience is required, and it should be a solid foundation.
But technical knowledge is not enough to succeed in this role, and you need more “humaning” skills like:
- communication and leadership
- navigating complexity
- putting your work in perspective
- mentorship, sponsorship, and delegation
- framing a problem so that other care about it
- acting like a leader whether you feel like one or not
Concerns
How much will I code as a staff engineer? Could I focus on technical side of things?
If your goal to become industry expert in a particular technical domain, find a more narrow area to focus on.
Do I need leadership/communication skills?
Technical skills will only take you this far. You would need them, but it doesn’t mean that you should be amazing at them.
Who is a staff engineer
Why do companies need staff engineers
All engineering organizations are constantly making decisions. And the best decision always “depends” on the context.
Companies need people who can make such decisions. People, who can take an outsider view, and avoid Local maxima to consider goals of multiple teams in the organization now and in the future. 
Creating good software isn’t easy or intuitive. Teams need senior people who have honed their skills, who have seen what succeeds and what fails, and who will take responsibility for creating software that works.
What is the job of staff engineer
- Leadership. You don’t lead as a manager, but by setting an example. By tackling complex problems, designing a “happy path” solutions.
- ”Technical” role. But it doesn’t mean that all you do is writing a lot of code. Other your time is more valuable to apply to other tasks that only you can do.
- Autonomous. At this level you don’t wait for managers tell you what you need to do, but you also need to tell them what can be done (with provided information and context they bring you).
- Technical direction. You need to make sure that all technical decisions that need to be made, are made, they made well, and they are written down.
- Communication. The more senior you become, the more you will rely on strong communication skills. This will make your job easier.
Role in the organization
It depends on the organization.
You can sit on a different levels in the organization ladder.
- When you report “high”, it will give you broad perspective and can be a unique and valuable experience.
- When you report “low”, you will get more attention from your manager, and it could be possible to focus on a single technical area. But in this case, make sure that you have a skip-level meetings with your manager’s manager, so you can stay connected to your organization’s goals.
Scope
It’s a domain, team/teams that you pay close attention to and have responsibility for, even w/o formal leadership role in the domain.
Reporting chain will likely affect your scope.
Scope can be ignored in crisis. You should be comfortable stepping outside your day-to-day job and doing what needs to be done.
Too broad or undefined scope
Possible cons:
- Lack of impact. Beware of spreading yourself too thin.
- Bottlenecking. You could become a bottleneck if every decision should be run by you.
- Decision fatigue. A lot of things in backlog - harder to decide on what focus at the given time.
- Missing relationships. Other engineers will also lose out of you not being enough time there for them.
Doing everything is a workplace is hard to operate. Better choose an area, have some success there, devote time to solve problem entirely, and then move to a different area.
Too narrow scope
Possible cons:
- Lack of impact. If the system is not critical, it doesn’t need your level of expertise. Dive deep on a single team/technology if it’s a core, mission-critical component.
- Opportunity cost. You can miss out on other important things in the org.
- Overshadowing other engineers.
- Overengineering.
Archetypes
- Tech lead. Partner with managers to guide the execution of one or more teams.
- Architect. Responsible for technical direction and quality across a critical area.
- Solver. Wade into one difficult problem at a time.
- Right hand. Add leadership bandwidth to an organization.
Primary focus
As you grow in influence, more people would want for you to care about things.
Most of the time you would have some autonomy in deciding what’s most important. Choose carefully, because you also choose what not to do as well.
Doing important work doesn’t mean working with the fanciest technologies. The most important work is the one that nobody else sees.
Know why the problem you’re working on is strategically important. If it’s not - do something else.
Your job is to make your organization successful. You do what you need to do to make the project happen. Even if it’s not on your job description.
Big-picture view of the organization
In the book it described in three maps:
- A locator map: you are here.
- A topographical map: weird political boundaries, difficult people to avoid etc.
- A treasure map: where you are going and intermediate stops on the journey.
Locator map: getting perspective where you are
The more time you focus on a domain and your scope, the more richer it becomes, you’ll gain more depth and understanding, but there are some risks:
- Bad prioritization. You could ignore things outside your scope, because you see them as simple or unimportant in comparison. See Local maxima.
- Lose empathy. You could start thinking that everything else as trivial compared to your rich and nuanced domain. Fish-eye lens.
- Tune out the background noise. You stop noticing problems at all. Some process or configuration started as slightly annoying can become a problem that is close to crisis, but you don’t even notice it anymore.
- Forget what the work is for. You may work on the project that initially should have been solve a larger goal, but it may already be solved in some other way in your organization or it’s no longer matters. Also, if you are working on a little part of the project, it’s easy to forget what the project is for, and when nobody feel like he’s responsible for the end result.
It’s important to be able to take an outsider view on your work, project, team to be able to see something that you can ignore being an insider.
Building relationships with other staff engineers in the organization is also beneficial. It’s your “staff engineer team”.
Same goes for principal engineers, but they are scoped to an organization.
Build relationships beyond engineering: product, customer support, administrative staff etc. Understand their point of view, it will give you a lot of stuff to think about on what’s important.
Remember that technology is a means to some end. Ultimate goal is to help your employer achieve its goals. Because of that it’s important to know them: explicit and implicit ones.
When the goal of the employer change, your scope or focus should change as well. It’s OK to not work on the most important thing, but what you are doing should not be a waste of time. If you can’t explain why you are working on something, then you might be doing the wrong thing.
Know what your customers care about. No reason to improve your technical KPIs, when the clients are unhappy with your product.
Your goal is to solve the problem, not necessarily to write code to solve it. “Respect what came before”. Analyze what already exists (inside and outside your org) before building something new. You’ll come up with better solutions.
Topographical map: navigate the terrain
There are some difficulties that you can face when you don’t fully understand the “terrain” of the organization. For example:
- Your ideas don’t get traction. You need to be able to convince other people that you are right, and convince them to care that you are right. You need to find a sponsor for your idea.
- You don’t find out about the difficult parts until you get there. Some trivial problem can have crucial point that nobody before you figured how to get past. But if you know about that in advance, you can tackle the hardest part of the problem first to convince others that the project worth their effort.
- Everything takes longer. You need to know how your organization works, so that you can plan when to present new initiative.