Milestone map
Milestone map
5 milestones
Find a problem nobody 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 that is on nobody's roadmap. It must cross team lines and get worse if ignored. Write a one-page problem brief, not a solution. Say what is happening, why it matters and who is affected. Say what happens if nothing changes in six months. Share it with at least two affected people outside your team before proposing a fix.
Proof required
Share the problem brief. You may anonymise details, but it must be real. Show you shared it with two people outside your team. A message, note or email works. Write 200 words on how you found the problem. Say what that shows about how staff engineers find work.
What gets checked
- The problem crosses team lines. If one team could fix it alone, it isn't staff scope.
- The brief states the problem without proposing a fix.
- It really was shared with two people outside the team.
Common mistakes
- Picking a problem your own team can fix. That's good senior work, not staff work.
- Proposing a fix in the same document. Leading with solutions creates resistance.
Powstik Guide
A brief on a real problem nobody assigned you.
Steps
- Spot a problem across teams.
- Write what it costs.
- Propose a first step.
- Share it with two people outside your team.
Template
Problem: Cost (evidence): Proposed first step: Shared with (roles):
What gets sent back
- Assigned work.
- Not shared outside your team.
- No cost evidence.
Resources
Foundationstart here
What a verifier looks for
- Ask whose roadmap it was on. If theirs, ask whether their team could fix it alone.
- Check the brief stops at the problem. A fix in the same document skipped the hard step.
- Ask why they picked those two people. Were they affected, or just easy to reach?
- Ask how people reacted. Reading reactions is a staff skill.
You'll sign in first, then come straight back here.
Write a technical strategy document
2–3 weeks. Writing the document takes a week. Circulating it and getting real feedback (not just approvals) takes another week, especially if you have to follow up with reviewers who are busy.
Take the Milestone 1 problem and write a strategy, not a detailed design. Restate the problem briefly. Give at least two viable approaches with honest trade-offs. No straw man to make your favourite look good. Recommend one and say why. Say what you are not solving yet. Get written feedback from three senior engineers or above, one outside your team.
Proof required
Share the strategy. Share at least three reviews in the reviewers' own words, as screenshots or exported comments. Write 200 words on the strongest pushback. Did it change your recommendation? If not, explain why you held your position.
What gets checked
- Both approaches are viable. A reasonable person could choose either.
- Feedback is real. At least one review challenges part of the document.
- The reflection engages with the objection, whether or not it changed your mind.
Common mistakes
- One option is obviously worse. Readers notice, and you lose credibility.
- Arguing disagreement away instead of engaging with it.
Resources
Foundationstart here
Depthgo deeper
Masteryfor the dedicated
What a verifier looks for
- Ask them to argue for the option they rejected. If they can't, it was a straw man.
- Is at least one review a real objection? If all approve, ask for a reviewer who disagrees.
- Ask what was right about the pushback, even if they didn't fully agree.
- Ask what they decided not to solve. A strategy that solves everything hasn't prioritised.
You'll sign in first, then come straight back here.
Influence a decision you don't own
2–4 weeks. Finding a decision in progress that you can meaningfully engage with takes longer than the engagement itself. The timing matters — too early and there is nothing concrete to respond to; too late and the decision is already made.
Find a decision another team is about to make. It must affect others, and you must have no authority over it. Join their process: attend the discussion, comment on the proposal, or talk to the owner. Don't try to override them. Make sure the wider impact is considered. Record what you raised and what changed.
Proof required
Describe the decision and the wider impact the team hadn't considered. Show how you raised it with the actual comment, meeting note or message. Write 250 words on the outcome. Did the decision change? If yes, say what changed. If no, say why, and whether that was right.
What gets checked
- The decision belonged to another team. You couldn't have made it yourself.
- The impact was specific and truly unconsidered. It needed your vantage point to see.
- The outcome is honest. A valid concern that didn't change the decision still counts.
Common mistakes
- Picking a decision you secretly have leverage over, like one owned by your manager's report.
- Raising the concern and disappearing. The proof needs the real result, even 'no change'.
Resources
Foundationstart here
Masteryfor the dedicated
What a verifier looks for
- Ask what formal authority they had. Any at all means this didn't test influence.
- Could the deciding team have seen the impact with basic care? Then it isn't staff-level.
- Read the actual artifact. Does it offer a way forward, or only criticise?
- Ask what they'd change about how they raised it.
You'll sign in first, then come straight back here.
Mentor someone toward your former level
12 weeks minimum, as specified. The capability gap definition takes a conversation or two to get right — most first attempts at naming a gap are too vague and need refinement before the 12 weeks of mentoring formally begins.
Pick one engineer one or two levels below you. Mentor them on one specific, named capability gap for at least 12 weeks. This is targeted skill transfer, not general career advice. Define the gap first. Meet regularly and track progress. By the end, they should be measurably closer to closing it, not just more confident.
Proof required
Share the gap you defined before starting. Show 12 weeks of regular meetings with a log, calendar or notes. Share the mentee's own statement on what changed. Write 200 words on what you had to unlearn to teach it.
What gets checked
- The gap is specific, like 'can't design a schema without senior review'. It was set first.
- Twelve weeks of regular meetings are documented, not one chat and a few check-ins.
- The mentee names something concrete they can now do.
Common mistakes
- The gap is about confidence or visibility, not a skill. This milestone needs a skill.
- Writing or heavily editing the mentee's statement. It must be in their own words.
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Could you judge whether the gap closed, with no context? If not, ask them to restate it.
- Is it a real 12-week log? Ask for dates and topics from three sessions.
- Does the statement sound like the mentee? If in doubt, speak to the mentee directly.
- Ask what the mentee still struggles with. Honest partial progress is a valid result.
You'll sign in first, then come straight back here.
Ship something that outlasts you
6+ months minimum, as specified. This milestone cannot be completed quickly by design — durability can only be proven by elapsed time. Start this milestone early in your Staff engineer journey so the 6-month clock has time to run alongside other work.
Build or drive something others keep using after you stop maintaining it. It could be a system, process, document or tool. This is the real test of staff-level leverage. Six months after you stop, check it's still used and by whom. Check whether it needed you.
Proof required
Describe what you built and when you stopped maintaining it. Show it's still in use six months later. Usage data, a user's message or current docs all work. Write 250 words on what made it last. Was it the design, the docs, the people you trained, or something else? Say what you'd do differently next time.
What gets checked
- Six months have really passed since you stopped maintaining it.
- Evidence of use comes from someone else or from system data, not your own claim.
- The analysis names one mechanism, like a trained successor or self-service design.
Common mistakes
- It only survived because you quietly kept answering questions about it.
- Picking something trivial that survives by default, like a channel name or unused wiki page.
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Get both dates: when maintenance stopped, and the evidence of use. At least six months apart.
- Is the evidence independent of the submitter? If not, ask for something concrete.
- Ask who they'd call if it broke today. 'Me' means it isn't durable.
- Ask what one thing kept it alive. It should match the mechanism they wrote down.
You'll sign in first, then come straight back here.