Milestone map
Milestone map
3 milestones
Redesign the engineering team structure
4 weeks
Assess how your engineering organisation is structured today. Propose a redesign judged on four criteria. They are team size, cognitive load per team, clear system ownership, and fewer dependencies. Document the current state and the proposed state. Give the reason for each change and list the risks of moving over. Present it to senior engineering and product leaders, and record their challenges.
Proof required
Submit the proposal, at least 1,000 words. Include a current-state diagram and a proposed-state diagram with reasons. Add a record of the Q&A where senior engineering or product leaders challenged it.
What gets checked
- Both states are diagrammed, not only described.
- Each change is argued against the criteria: load, ownership, dependencies.
- The Q&A shows real challenges from senior leaders.
Common mistakes
- The redesign has no criteria. It's a reorganisation without a model.
- Nobody challenges it. It was shown only to a junior or friendly audience.
- Transition risks are skipped. That's the hardest part of the plan.
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Ask them to defend one boundary. Why there and not somewhere else?
- Confirm the Q&A involved senior engineering or product leaders, not peers.
- Check the transition risks are real. What could fail, and how would they know?
You'll sign in first, then come straight back here.
Build and run an engineering hiring process
6 weeks
Design and run a hiring process for at least two engineering roles. Cover the job spec, sourcing, screening criteria, interview loop, scoring rubric and offer. Write it down so another engineering manager could run it without you. Run at least three full interview loops. Make hire or no-hire calls with written reasons. Debrief at least one decision with the whole panel.
Proof required
Submit the written process, at least 800 words. Add the rubric for at least one role. Add debrief notes for one decision, showing evidence and reasoning. A senior engineer or people partner confirms the process ran and the debrief was real.
What gets checked
- Another engineering manager could run the process as written.
- Hire or no-hire reasons tie to the rubric, not gut feel.
- The debrief includes the whole panel, not only the hiring manager.
Common mistakes
- The document exists but was never run.
- The debrief is shallow: no panel, no review of the evidence.
- The rubric is generic, like 'good communicator', not specific and testable.
Powstik Guide
An 800-word hiring process with a rubric and debrief notes.
Steps
- Map every stage from sourcing to offer.
- Write a rubric for one role.
- Run the process for a real hire.
- Keep debrief notes.
Template
Stages: Rubric (role): Debrief notes (anonymised):
What gets sent back
- Under 800 words.
- No rubric.
- No real hire run.
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Confirm two roles and at least three full interview loops.
- Ask them to walk through one decision. What was the evidence, and what was borderline?
- Confirm the whole panel joined the debrief, not only the submitter.
You'll sign in first, then come straight back here.
Deliver OKRs across three teams
12 weeks
Run a full OKR cycle across at least three engineering teams you lead. Link the OKRs to company goals. Write them with the teams, not for them. Hold a mid-cycle review and record the changes you made. At the end, write a retrospective: what shipped, what missed and why. Say what you'd change about the OKR process itself. Present it to engineering leadership.
Proof required
Submit the OKRs for all three teams with every key result. Add mid-cycle notes showing at least one change. Add the retrospective, at least 600 words. An engineering director, executive or product leader confirms the cycle ran and was presented.
What gets checked
- OKRs link to named company goals, not standalone engineering metrics.
- The mid-cycle review made at least one real change, with reasons.
- The retrospective names specific process failures, not just outcomes.
Common mistakes
- OKRs are handed down. Teams don't own them and miss them.
- The mid-cycle review is skipped, or becomes a status update.
- The retrospective lists what shipped but skips the process critique.
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Ask what they changed mid-cycle and why. The reason shows whether the review was real.
- Confirm the teams helped write the OKRs.
- Confirm the retrospective was presented to engineering leadership, not kept private.
You'll sign in first, then come straight back here.
Part of