Milestone map
Milestone map
3 milestones
Map the CTO Function
3 weeks
Audit what the CTO role covers in your organisation: technical strategy ownership, engineering people management, cross-functional product alignment, board/investor reporting, and vendor/partner decisions. Interview or shadow an existing CTO or VP Eng to surface the invisible parts. Produce a written role-scope document that separates the technical-leadership accountabilities from the engineering-management accountabilities.
Proof required
Submit your CTO role-scope document (min 800 words) showing at least five distinct accountability domains with concrete examples from your context. Include a reflective paragraph on which domains you are currently strongest and weakest in, reviewed by a senior technical leader (CTO/VPE/CTO emeritus) who can challenge your self-assessment.
What gets checked
- Document names five or more distinct CTO accountability domains with concrete examples
- Self-assessment is challenged in documented Q&A with a named senior technical leader
- Weakest domains are identified honestly, not just strengths
Common mistakes
- Conflating CTO with VP Engineering — treating people management as the whole role
- Skipping the shadow/interview step and producing a generic job description instead
- Self-assessment remains unchallenged — reviewer signs off without probing gaps
Resources
Foundationstart here
Depthgo deeper
Masteryfor the dedicated
What a verifier looks for
- Ask the submitter to explain one accountability domain they identified as a weakness — how would they develop it?
- Verify the reviewer is a named CTO, former CTO, or VP Engineering with direct experience in the role
- Check that the document was produced from real research (interview notes, shadow observations) not from a generic job description
Build a Three-Year Technical Strategy
4 weeks
Produce a written three-year technical strategy for your organisation or a realistic target organisation. The strategy must cover: current technical state assessment, business goals the technology must enable, three-to-five strategic bets with rationale, investment prioritisation framework, and the make-vs-buy-vs-partner decisions on at least two meaningful capability gaps. Present it to at least two senior stakeholders (CEO, board member, or senior engineer) and document their challenges and your responses.
Proof required
Submit the three-year technical strategy document (min 1200 words) plus a Q&A record from the presentation to senior stakeholders, showing specific challenges raised and your responses.
What gets checked
- Strategy explicitly links technical bets to named business goals
- Make-vs-buy-vs-partner decision is argued for at least two capability gaps
- Q&A record shows real challenges, not softball questions — reviewer must confirm
Common mistakes
- Strategy is a technology wishlist rather than a response to business goals
- Presentation audience is too junior — no one challenges the strategic assumptions
- Make/build/partner analysis is superficial — no cost, risk, or capability reasoning
Resources
Foundationstart here
Depthgo deeper
Masteryfor the dedicated
What a verifier looks for
- Ask the submitter to defend one strategic bet — what would cause them to abandon it?
- Verify at least one challenge in the Q&A record was a genuinely hard question, not confirmatory
- Confirm the make/buy/partner reasoning is specific to this organisation, not generic principles
Lead a Board-Level Technical Narrative
3 weeks
Prepare and deliver a technical narrative to a board, investor group, or executive leadership team — not a technical briefing but a business-framed story that explains why technical decisions are strategic assets or risks. The narrative must cover: one technical risk and the mitigation plan, one technical investment and the expected business return, and the engineering team's capacity to execute the strategy. Collect structured feedback from at least one board member or equivalent and document a follow-up action.
Proof required
Submit the board-level narrative deck or document (min 8 slides or equivalent) plus written feedback from at least one board member or C-suite executive, and a documented follow-up action you took based on that feedback.
What gets checked
- Narrative is business-framed — technical risks expressed as business risks, investments as business returns
- Feedback from a named board member or C-suite executive is included and is substantive
- Follow-up action is concrete and traceable — not 'will consider it'
Common mistakes
- Deck is a technical briefing — engineering metrics without business framing
- Feedback is from internal engineering team rather than a board or C-suite member
- No documented follow-up — the narrative produced no visible action
Resources
Foundationstart here
What a verifier looks for
- Confirm the feedback came from a board member, investor, or C-suite — not internal engineering leadership
- Ask the submitter what they changed after the narrative — what follow-up action did the feedback produce?
- Check the narrative translates technical risk into business terms — not 'our stack is outdated' but 'this creates an X-month competitor advantage risk'
Part of