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
0 of 5 done
Current milestone
Identify a problem no one assigned you
2–4 weeks. Most of this time is noticing, not writing. The brief itself takes a day. Recognising that a recurring annoyance is actually a cross-team problem worth naming takes much longer and cannot be rushed.
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
Foundation: start here · Depth: go deeper · Mastery: for the dedicated
Write a technical strategy document
Influence a decision you do not own
Mentor someone toward your former level
Ship something that outlasts your involvement
Sign in to start this outcome and track your progress publicly.
Sign in to start this outcome →