Operate as a Staff Engineer

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

Common mistakes

• Picking a problem that is actually within your own team's authority to fix — this is good Senior-level work but does not test the cross-team influence that defines Staff scope
• Writing the brief and immediately proposing a solution in the same document — Staff engineers who lead with solutions before establishing shared understanding of the problem create resistance, not alignment

Resources

Arena

What a verifier looks for

• Ask: 'Which team's roadmap was this problem already on?' If the answer is 'my own team's,' ask a follow-up: 'Could your team have solved this without any other team's involvement?' If yes, this is not a cross-team problem.
• Read the problem brief. Does it propose a solution, or does it stop at establishing the problem? A brief that proposes a fix in the same document as the problem statement has skipped the harder, more important step.
• Check the sharing evidence. Were the two people outside the immediate team actually affected by the problem, or were they chosen because they were easy to reach? Ask the submitter why they chose those two specific people.
• Ask: 'What was the reaction when you shared the brief?' A founder-level Staff engineer skill is reading reactions — skepticism, agreement, disinterest — and adjusting the approach. If the submitter cannot describe the reaction in detail, they may not have shared it broadly enough to generate one.

You'll sign in first, then come straight back here.

Proof required

Share the strategy document. Share the written feedback you received — at least three distinct responses, not summarised by you but in the reviewers' own words (screenshots or exported comments). Write 200 words on the most substantive pushback you received — what was the objection, and did it change your recommendation? If it did not change your recommendation, explain why you held your position.

What gets checked

• Two viable approaches are genuinely viable — not one real option and one strawman; a reviewer reading both options should be able to imagine a reasonable person choosing either one
• Feedback is real and substantive — three one-word 'looks good' responses do not count; at least one piece of feedback must challenge part of the document
• The pushback reflection shows genuine engagement with the objection — either the recommendation changed with a clear explanation of why, or it did not change with a clear explanation of why the objection was addressed or did not apply

Common mistakes

• Writing two options where one is obviously worse — readers can tell when an option exists only to make the author's preferred choice look better; this destroys credibility rather than building it
• Treating disagreement as something to manage away rather than engage with — if a senior reviewer pushes back and the response is to explain why they are wrong without considering whether they have a point, this is not the Staff-level skill of synthesising disagreement

Resources

What a verifier looks for

• Read both proposed approaches. Could you imagine a competent engineer genuinely preferring the one the submitter did not choose? If not, ask the submitter to defend the rejected option as strongly as they can — if they cannot, it was a strawman.
• Read the three pieces of feedback. Is at least one of them substantive — a real objection or question, not agreement? If all three are approvals with no challenge, ask the submitter to find a fourth reviewer who disagrees with something.
• Check the pushback reflection. Does it show the submitter actually considering the objection, or does it read as a rebuttal written to win the argument? Ask: 'What was right about the pushback, even if you didn't fully agree?' A Staff engineer can usually find something true in even an objection they ultimately reject.
• Ask: 'What did you explicitly decide NOT to solve in this strategy?' If the document tries to solve everything, it has not made the hard prioritisation calls that strategy requires.

You'll sign in first, then come straight back here.

Proof required

Share a description of the decision being made, what cross-team impact you identified that the team had not considered, and how you raised it (a comment, a meeting, a written note — show the actual artifact). Write 250 words on the outcome: did the decision change because of your input? If yes, what changed specifically. If no, why not, and was that the right outcome anyway?

What gets checked

• The decision genuinely belonged to another team — not a decision the submitter could have made unilaterally; if the submitter had formal authority over this decision, the milestone is not testing influence without authority
• The cross-team impact identified is specific and was genuinely not already considered — not a generic concern that any reviewer would raise, but something that required the submitter's particular vantage point to see
• The outcome is reported honestly — if the decision did not change and the submitter's concern was valid, this should be named as a real outcome (not every influence attempt succeeds, and reporting failure honestly is part of the proof)

Common mistakes

• Choosing a decision where you secretly have informal authority (e.g. the decision owner reports to your manager, or you have personal leverage over them) — the milestone tests influence through the quality of the argument, not through organisational leverage
• Raising the concern but not following through to see what happened — Staff engineers who raise issues and disappear are not actually influencing outcomes; the proof requires documenting the actual result, including if it was 'no change'

Resources

What a verifier looks for

• Ask: 'What formal authority did you have over this decision?' If the answer reveals any direct authority (the decision owner reports to the submitter, or the submitter could have escalated to override it), this milestone has not tested influence without authority.
• Read the cross-team impact identified. Could anyone on the deciding team have seen this themselves with basic diligence? If yes, the insight was not Staff-level — it should be something that required the submitter's specific vantage point or expertise to surface.
• Check the artifact — the actual comment, meeting note, or message. Does it raise the concern constructively, or does it read as criticism without offering a path forward? The tone of the artifact reveals whether this built or damaged the relationship.
• Ask: 'If you had to do this again, what would you change about how you raised it?' A Staff engineer reflecting honestly on their influence attempts, win or lose, has the self-awareness this role requires.

You'll sign in first, then come straight back here.

Proof required

Share the capability gap you defined at the start (written before mentoring began). Share evidence of regular meetings over 12 weeks (a log, calendar history, or meeting notes). Share a written statement from the mentee describing what changed in their capability — in their own words, not yours. Write 200 words on what you had to unlearn about how you do the work yourself in order to teach it effectively.

What gets checked

• Capability gap is specific and was defined before mentoring started — not 'become a better engineer' but 'cannot yet design a database schema for a new feature without senior review' — a gap specific enough that progress against it can be assessed
• 12 weeks of regular meetings are evidenced — not a single conversation followed by occasional check-ins; the cadence must be real and documented
• The mentee's own statement, in their words, describes a specific change — not a generic 'X helped me grow' but something concrete the mentee can now do that they could not before

Common mistakes

• Choosing a gap that is actually about the mentee's confidence or visibility rather than a skill — 'they need to speak up more in meetings' is a real issue but is a different kind of mentoring than closing a technical capability gap, which is what this milestone requires
• Writing the mentee's statement for them or heavily editing it — the proof requires the mentee's own assessment in their own words; if it reads like the mentor's voice, ask the mentee to rewrite it independently

Resources

What a verifier looks for

• Read the capability gap definition. Is it specific enough that you, as a verifier with no context, could assess whether it was closed? If the gap is vague, ask the submitter to restate it more specifically before continuing.
• Check the meeting evidence. Is it a real log spanning 12 weeks, or a summary written at the end claiming regular meetings happened? Ask for specific dates and what was covered in at least three different sessions.
• Read the mentee's statement carefully. Does it sound like the mentee's own voice, or does it read like something the mentor wrote and the mentee approved? Ask to speak with the mentee directly if there is any doubt — their own account, unprompted, is the strongest verification.
• Ask the submitter: 'What is your mentee still struggling with after 12 weeks?' A mentor who can name remaining gaps honestly understands that 12 weeks rarely fully closes a capability gap — partial progress, honestly assessed, is a valid and common outcome.

You'll sign in first, then come straight back here.

Proof required

Describe what you built or drove and when you stopped actively maintaining it. Share evidence that it is still in active use at least 6 months later — usage data, a message from a current user, or a reference to it in current documentation or processes. Write 250 words on what made this durable: was it the design, the documentation, the people you trained, or something else? What would you do differently to make your next piece of leveraged work even more durable?

What gets checked

• Six months have genuinely passed since the submitter stopped active maintenance — this cannot be rushed or approximated; the milestone requires real elapsed time to prove durability
• Evidence of continued use is from someone other than the submitter, or from system data that does not require the submitter's continued involvement to generate — self-reported 'I think people still use it' is insufficient
• The durability analysis identifies a specific mechanism (clear documentation, a trained successor, a self-service design, embedded tests) — not a vague 'it was well built'

Common mistakes

• Choosing something that only survived because you secretly kept maintaining it informally — if 'stopped actively maintaining' means 'stopped doing the work but still answered questions about it weekly,' the durability has not actually been tested
• Choosing something trivial that survives by default (a Slack channel name, a wiki page no one needed to change) rather than something that required real engineering or organisational leverage to create and that genuinely needed to be durable to matter

Resources

What a verifier looks for

• Confirm the 6-month elapsed time is real — ask for the date the submitter stopped active maintenance and the date of the evidence of continued use. The gap between them must be at least 6 months.
• Check the evidence of continued use. Is it independent of the submitter — system usage data, or a message from someone else? If the only evidence is the submitter's own assertion that 'people still use it,' ask for something more concrete.
• Ask: 'Who would you call if this broke today?' If the answer is 'me, because no one else understands it,' the work has not actually achieved durability regardless of whether it is technically still running.
• Read the durability analysis. Does it name a specific mechanism? Ask the submitter: 'What is the one thing that, if you had not done it, would have caused this to die when you stopped maintaining it?' Their answer should match the mechanism named in the written reflection.

You'll sign in first, then come straight back here.