📎 Webclip
Beyond Staff Engineer
Alex Ewerlöf expected the jump from Staff Engineer to Senior Staff Engineer to mean the same job at a larger scale: more people, more technologies, more depth. Twenty months in, he says that model was wrong. The role doesn’t add more of the same thing; it trades hands-on depth for a different toolbox entirely.
He grounds the Staff Engineer role itself in the military use of “staff”: officers who assist commanders with planning and analysis but hold no command authority over subordinates. Staff Engineers, in his reading, play the same role for engineering leaders, serving as trusted technical advisors without direct reports.
Fichamento#
- Staff Engineer is an individual-contributor role without people management, filling a technical gap that engineering managers responsible for larger orgs don’t have time to cover themselves; he counts at least four archetypes (right hand, solver, tech lead, architect), and says he doesn’t buy the value of the architect archetype specifically.
- Moving to Senior Staff means less hands-on coding time and more time spent building trust, finding and verifying information, and accepting that other people know more than you do about any given area.
- Delegation becomes central: ideas get implemented through other people’s hands, so coaching, mentorship, sponsorship, and setting standards replace direct execution.
- The time horizon for measuring a “good day” stretches out; where a Senior Engineer’s good day was shipping good code, a Senior Staff Engineer’s good quarter is progress toward a strategic objective, with impact that’s rarely immediate.
- The network of people involved grows roughly 10x compared to Staff Engineer, which breaks the effectiveness of 1:1s and slide decks at that scale; he lists writing, video, delegation, and temporary task forces as the tools he uses instead.
- He frames the higher level as higher responsibility rather than higher authority: a Senior Staff Engineer has no formal authority over Staff Engineers or Senior Engineers, so influence depends on being service-minded toward the engineers actually writing the code.
- His closing filter for whether to pursue this path: curiosity and a growth mindset make it viable, chasing prestige or pay makes it a hard ride, and wanting to move away from code altogether is a sign to stop.
