How to Become a Staff Engineer: 5 Signals That Matter
Concrete behaviours and evidence you can start building this sprint.
Last summer, I was hanging out with a couple of friends, and we were sharing our experiences about growing in a tech company. None of us works at a big US tech company, but our companies are still fairly large, around a thousand employees worldwide, with engineering headquarters in Spain. Our roles ranged from Tech Lead to Principal Engineer.
One important thing that we all agreed on was that:
Becoming Staff Engineer isnโt about titles: itโs the sum of repeated habits that make your impact visible beyond your team.
From there, after a few drinks and some tapas, we ended up agreeing on what actions really help you reach the role of Staff Engineer. I think itโs something worth sharing with you.
In todayโs email, I share with you a checklist that you can follow to get a Staff Engineer position.
If you are a Senior Software Engineer looking for an strategy to board a Staff Engineer position, this email is for you. Or maybe for somebody else; in such a case, you send it right away ๐๐ป
Letโs go straight to the checklist.
1๏ธโฃ You delivered your commitments
โ๐ผ In every sprint, within your team, you delivered the commitments that you and your team agreed on.
Like a hammer.
Wait, does this mean that I have to ensure that the sprints (working in Scrum) of my team are green every time?
Not exactly. The sprint commitments are one thing; here, I talk about something else.
๐๐ผ You must make delivery credibility a habit.
That means not only shipping but owning the whole delivery lifecycle:
Estimate properly.
Document assumptions.
Call out risks during planning.
Raise blockers immediately.
Post-mortem the misses with a short โwhat I learned / what I changedโ note.
Now, the most important part: give visibility!
How you show it: keep a log of 6โ12 sprint notes you can point to in one-on-ones with your Engineering Manager. I have a template for you on this at the end of this email.
2๏ธโฃ You worked outside of your team
โ๐ผ Somehow, you managed to find time to work on other initiatives, outside of your team, that helped others.
Pick a recurring, time-boxed slot and use it for cross-team work. Some examples:
Fix a shared library.
Own an observability monitor.
Review critical PRs for other squads.
Mentor a mid-squad on a production bug.
Small, repeated contributions pay off: people remember who reduces friction across teams.
๐๐ผ Donโt wait for invitations.
Again, make this work visible!
How you show it: In my template (see end of the email), I call this โinvisible winsโ. When asked about scope, you can point to measurable, cross-team improvements rather than isolated features. Staff engineers are measured on scope beyond their immediate codebase.
3๏ธโฃ You implemented solutions to problems impacting the Engineering organization
โ๐ผ And not only for your team. Again, you found time for this somehow.
Go hunting for recurring pain. For example:
Noisy on-call alerts (my favourite ones).
Lengthy CI runs (somebody said private runners in GitHub workflows?).
Deployment pain.
Flaky tests.
Manual runbooks.
๐๐ผ When you design a solution, think in terms of platformizing it.
A one-off hack that reduces a single incident is nice; a small engineering investment that reduces weekly toil for multiple teams is promotion-grade work.
Did I say make your work visible aleady?
How you show it: quantify the impact somehow (hours saved per week, mean time to recovery improvement, reduction in failed deploys) and put it in the โinvisible winsโ from my template.
4๏ธโฃ You proposed and led experiments and edge initiatives
โ๐ผ Get out of your comfort zone. Innovate. Propose something that leading-edge companies are starting to do.
I consider experimentation to be more important than ever, nowadays, in the awakening of AI for developers.
When I propose an experiment to my engineering group, I tend to follow this pattern:
State a clear hypothesis.
Pick 1โ3 metrics (no more).
Define a short timebox and a minimal scope to validate the idea.
Run the experiment, collect results, and publish a concise conclusion (what worked, what didnโt, and propose the next step).
Leading experiments show you can de-risk strategy and shepherd learning across org boundaries.
If the experiment involves some friendly teams, follow up and ensure adoption of the experiment.
๐๐ผ Treat new ideas like experiments, not edicts.
And yes, this work you have make it visible too!
How you show it: As usual, you tell your Engineering Manager during the one-on-ones, but I also recommend that you make this experiment public, for example, in the Slack channel for your engineering group. Everybody should be aware of it.
By the way, do you want to read a real experiment I recently started? Follow up on this Good Practices Creating AGENTS.md.
5๏ธโฃ You appeared and showed up in cross-Engineering meetings and discussions
โ๐ผ Provide confident, realistic, and experience-based opinions.
When you speak in architecture reviews, incident retros, or leadership syncs, bring concise, data-backed options and trade-offs. Donโt position ideas as absolute; propose next steps and volunteers for follow-through.
Influence at the Staff level is primarily practical: you change decisions and unblock teams, not just pontificate (love this word).
๐๐ผ Presence matters, but content matters more.
Yeah, I know, Iโm such a pain sometimes, but make your work visible!
How you show it: keep a short list of decisions you influenced; explaining concrete decisions you drove is far more persuasive than abstract claims of leadership. I would advice to show this during one-on-ones, instead waiting to the career conversations.
Letโs wrap up for today but, before that:
Which of these 5 practices do you find most difficult to consolidate? Tell me by replying this email or send me a new one and I give you a hand on this
โจ Summary
I wonโt lie to you: moving to Staff Engineer is not an easy task. Keep that sentence in mind.
The process to reach Staff Engineer, from Senior Software Engineer, could take you a couple of years. As usual, depends on the context of your company:
In hypergrowth, the promotions fly like swallows in spring.
At other stage, it could be more difficult.
You main challenges?
Find time to make those 5 points happen. You have your team responsibilities as well, so you have to balance your time, based on the priorities and your priorities.
Make your work visibile! Did I say this already? Maybe 5 times, donโt know, but just in case, one more time: Make your work visible for the rest of your engineering organization.
From my experience, following those 5 points will put you in a good position to obtain a Staff Engineer position.
Hope it helps!
Thanks for your support and feedback, I really appreciate it!
Youโre the best! ๐๐ผ
๐๐ง ๐บ๐ฐ๐ถ ๐ฆ๐ฏ๐ซ๐ฐ๐บ๐ฆ๐ฅ ๐ต๐ฉ๐ช๐ด ๐ฑ๐ฐ๐ด๐ต, ๐ต๐ฉ๐ฆ๐ฏ ๐ค๐ญ๐ช๐ค๐ฌ ๐ต๐ฉ๐ฆ ๐. ๐๐ต ๐ฉ๐ฆ๐ญ๐ฑ๐ด!
๐๐ง ๐บ๐ฐ๐ถ ๐ฌ๐ฏ๐ฐ๐ธ ๐ด๐ฐ๐ฎ๐ฆ๐ฐ๐ฏ๐ฆ ๐ฆ๐ญ๐ด๐ฆ ๐ธ๐ช๐ญ๐ญ ๐ฃ๐ฆ๐ฏ๐ฆ๐ง๐ช๐ต ๐ง๐ณ๐ฐ๐ฎ ๐ต๐ฉ๐ช๐ด, โป๏ธ ๐ด๐ฉ๐ข๐ณ๐ฆ ๐ต๐ฉ๐ช๐ด
Template
Here is the template I have to log the progress on the different points mentioned in todayโs email.
