Milestone map
Milestone map
3 milestones
Redesign Engineering Team Structure
4 weeks
Evaluate your current engineering organisation structure and produce a redesign proposal. The proposal must be grounded in explicit criteria: team size norms (two-pizza or similar), cognitive load per team, system ownership clarity, and cross-team dependency minimisation. Document the current state, the proposed state, the rationale for each structural change, and the transition risks. Present to senior engineering and product leadership and document their challenges.
Proof required
Submit your team structure redesign proposal (min 1000 words), including current-state diagram, proposed-state diagram with rationale, and a documented Q&A session with senior engineering or product leadership who challenged the proposal.
What gets checked
- Current state and proposed state are diagrammed — not just described
- Each structural change is argued against explicit criteria (cognitive load, ownership, dependencies)
- Q&A record shows genuine challenges to the proposal from senior leadership
Common mistakes
- Redesign is not grounded in criteria — it's a reorganisation without a model
- Proposal is not challenged — presented to junior or friendly audience only
- Transition risks are not documented — the proposal skips the hardest part
Resources
Foundationstart here
Depthgo deeper
Masteryfor the dedicated
What a verifier looks for
- Ask the submitter to defend one structural choice — why that boundary and not a different one?
- Verify the Q&A involved senior engineering or product leadership, not peers
- Check the transition risks section is substantive — what would fail and how would they catch it?
You'll sign in first, then come straight back here.
Build and Own an Engineering Hiring Process
6 weeks
Design, document, and run a complete engineering hiring process for at least two roles — covering job specification, sourcing strategy, screening criteria, interview loop design, evaluation rubric, and offer process. Produce a written process document that another engineering manager could run without you. Conduct at least three full interview loops end-to-end, make hire/no-hire decisions with documented rationale, and debrief at least one decision with the hiring panel.
Proof required
Submit the written hiring process document (min 800 words), interview rubric for at least one role, and debrief notes from one hire/no-hire decision showing the evidence and reasoning. A senior engineer or people partner must confirm the process was run and the debrief was substantive.
What gets checked
- Process document is detailed enough for another EM to run without modification
- Hire/no-hire rationale is evidence-based — tied to rubric criteria, not gut feel
- Debrief involves the full panel — not just the hiring manager's self-review
Common mistakes
- Process document exists but wasn't actually run — theory without practice
- Debrief is superficial — no panel, no structured evidence review
- Evaluation rubric is generic ('good communicator') rather than role-specific and testable
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Confirm the process was run for at least two roles with at least three full interview loops
- Ask the submitter to walk through one hire/no-hire decision — what was the evidence, what was borderline?
- Verify the debrief involved the full panel, not just the submitter's self-assessment
You'll sign in first, then come straight back here.
Deliver Engineering OKRs Across Three Teams
12 weeks
Set, track, and close out a full OKR cycle across at least three engineering teams that you manage or lead. The OKRs must connect to company goals, be co-authored with the teams (not handed down), and include a mid-cycle review with documented adjustments. At cycle end, produce a written retrospective covering what shipped, what missed and why, and what you would change about the OKR process itself. Present the retrospective to the engineering leadership group.
Proof required
Submit the OKR set (all three teams, all key results), mid-cycle review notes showing at least one adjustment, and the cycle retrospective document (min 600 words). An engineering director, C-suite member, or product leadership stakeholder must confirm the cycle ran and the retrospective was presented.
What gets checked
- OKRs link to named company goals — not standalone engineering metrics
- Mid-cycle review shows at least one real adjustment with documented rationale
- Retrospective identifies specific process failures — not only outcomes
Common mistakes
- OKRs are handed down, not co-authored — teams don't own them and predictably miss
- Mid-cycle review is skipped or is a status update rather than an adjustment session
- Retrospective only covers what shipped — skips the process critique
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Ask the submitter what they changed at mid-cycle and why — the rationale reveals whether the review was real
- Confirm the OKRs were co-authored with teams, not set by the VPE alone
- Verify the retrospective was presented to engineering leadership — not just written privately
You'll sign in first, then come straight back here.
Part of