Operate as a Staff Engineer
20 weeks · 5 milestones
Staff Engineer is the most misunderstood title in the industry. Many companies hand out the title for tenure or as a retention tool, without the person ever doing Staff-level work. This outcome's proof standard is about the WORK, not the title — every milestone tests for influence without authority, the hardest skill at this level. The defining shift from Senior to Staff is scope: a Senior engineer is excellent within a defined problem. A Staff engineer identifies which problems matter before anyone assigns them, and influences outcomes across teams they do not manage.
Milestone map
Milestone map
5 milestones
Find a real technical or organisational problem at your company that is not on anyone's roadmap, that crosses team boundaries, and that will get worse the longer it is ignored. Write a one-page problem brief — not a solution, a problem statement: what is happening, why it matters, who is affected, and what happens if nothing changes in 6 months. Share it with at least two people outside your immediate team who are affected by the problem, before proposing any fix.
Proof required
Share your problem brief (anonymised company/project details if needed, but the structure and substance must be real). Share evidence that you shared it with at least two people outside your team — a message thread, a meeting note, or an email (redacted as needed). Write 200 words on how you found this problem — was it something you noticed in your own work, something a teammate mentioned in passing, or something you went looking for? What does your answer reveal about how Staff engineers find problems that no one assigned?
What gets checked
- The problem genuinely crosses team boundaries — not a problem entirely within the submitter's own team's control; if one team could fix it alone without coordination, it does not require Staff-level scope
- The brief separates problem from solution — a document that jumps straight to 'we should build X' has skipped the hardest part, which is articulating why the problem matters before anyone has bought into a fix
- Evidence of sharing with two people outside the immediate team is real, not hypothetical — a problem brief that has never left the submitter's own head is not yet doing Staff work
Resources
Enroll free to unlock learning resources →Mastery
How to write an engineering strategy — Will Larson
Will Larson's free framework for writing engineering strategy documents. Read after your problem brief is shared — this is the next-level document you write once the problem is acknowledged and you are proposing a direction.
Unlocks after completing Foundation + Depth