Milestone map
Milestone map
3 milestones
Map what the CTO role covers
3 weeks
Work out what the CTO role covers where you work. Look at technical strategy, people management and alignment with product. Also look at board reporting and vendor decisions. Interview or shadow a CTO or VP Engineering to find the parts you can't see. Write a scope document. Separate technical leadership duties from engineering management duties.
Proof required
Submit the scope document, at least 800 words, with five or more areas of responsibility. Give a concrete example from your context for each. Add a paragraph on where you are strongest and weakest. A senior technical leader reviews it and challenges your self-assessment.
What gets checked
- Five or more distinct areas, each with a concrete example.
- A named senior technical leader challenges the self-assessment in a recorded Q&A.
- Weak areas are named honestly, not only strengths.
Common mistakes
- Treating the CTO role as people management only. That's the VP Engineering role.
- Skipping the interview or shadowing. The result reads like a generic job description.
- The reviewer signs off without probing the gaps.
Powstik Guide
An 800-word map of what the CTO role covers.
Steps
- List five or more areas of responsibility.
- Give a concrete example for each.
- Mark which ones you already own.
- Name the biggest gap.
Template
| Area | Example | Do I own it? | |------|---------|--------------| Biggest gap:
What gets sent back
- Under 800 words.
- Fewer than five areas.
- No concrete examples.
Resources
Foundationstart here
Depthgo deeper
Masteryfor the dedicated
What a verifier looks for
- Ask about one weak area. How would they build it?
- Confirm the reviewer is a named CTO, former CTO or VP Engineering.
- Check it came from real research, like interview or shadowing notes.
You'll sign in first, then come straight back here.
Build a three-year technical strategy
4 weeks
Write a three-year technical strategy for your organisation, or a realistic target organisation. Assess the current technical state. Name the business goals technology must enable. Set three to five strategic bets, with reasons. Add a way to prioritise investment. Decide build, buy or partner for at least two real capability gaps. Present it to at least two senior people. The CEO, a board member or a senior engineer all count. Record their challenges and your answers.
Proof required
Submit the strategy, at least 1,200 words. Add a record of the Q&A, showing the challenges raised and your answers.
What gets checked
- Each bet links to a named business goal.
- Build, buy or partner is argued for at least two gaps.
- The Q&A shows hard questions, and the reviewer confirms it.
Common mistakes
- The strategy is a technology wishlist, not a response to business goals.
- The audience is too junior. Nobody challenges the assumptions.
- The build, buy or partner case skips cost, risk and capability.
Resources
Foundationstart here
Depthgo deeper
Masteryfor the dedicated
What a verifier looks for
- Ask them to defend one bet. What would make them drop it?
- Confirm at least one question in the Q&A was genuinely hard.
- Check the build, buy or partner reasoning fits this organisation, not general rules.
You'll sign in first, then come straight back here.
Tell a technical story to the board
3 weeks
Prepare and give a technical narrative to a board, investors or the executive team. Frame it as a business story, not a technical briefing. Show why technical decisions are strategic assets or risks. Cover one technical risk and its mitigation. Cover one technical investment and its expected business return. Cover whether the team can deliver the strategy. Get structured feedback from at least one board member or equivalent. Record one follow-up action.
Proof required
Submit the deck or document, at least 8 slides or equal. Add written feedback from at least one board member or executive. Add the follow-up action you took.
What gets checked
- Framed for business: risks as business risks, investments as business returns.
- Real feedback from a named board member or executive.
- A concrete follow-up action, not 'will consider it'.
Common mistakes
- The deck is a technical briefing, with engineering metrics and no business framing.
- Feedback comes from the engineering team, not the board or executives.
- No follow-up is recorded. The narrative changed nothing.
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Confirm the feedback came from a board member, investor or executive.
- Ask what they changed afterwards, and which feedback led to it.
- Check risks are in business terms. Not 'our stack is old', but what it costs the company.
You'll sign in first, then come straight back here.
Part of