Run the CTO 90/180/365-Day Scorecard Review

Use this skill when the user wants to run a 90-day, 180-day, or one-year review of a sitting CTO (or comparable technology executive) against their original mandate - organizing evidence by the book's own review questions and role-specific criteria…

This skill is Labor as Code™ for "Agree on the Test Before You Hire," the chapter of The CTO You Actually Need that builds the book's three structured reviews. Read that chapter in full for the reasoning - this skill executes the review mechanics (organizing evidence against the entry agreement, applying the right role-specific lens) and concludes with a recommendation and its reasoning, the same as the rest of the evidence pack: readable, cited, and open to the reviewers' own correction, never a black-box verdict.

This skill states a recommendation, with its reasoning, among the book's own four review outcomes - it does not stop at an evidence pack the reader is left to interpret alone. It is not a numeric score, and it is not a stand-in for the direct conversation the CEO, board, or the CTO's direct manager still has to have with the CTO and the people who work with them - the book is right that the decision belongs to that conversation, not to a table. But a recommendation with its reasoning shown, sitting alongside the evidence it came from, is more useful to that conversation than a pile of organized facts and no read on what they add up to. Where the evidence genuinely supports more than one outcome - a real judgment call, not a close-your-eyes guess - this skill says so and lays out the live options side by side with what would separate them, rather than forcing a single answer. Where the evidence is too thin to support any recommendation, it says that plainly and names what's missing, rather than picking an outcome to sound decisive.

Before running

Confirm with the user, in plain conversation, before gathering anything:

1. Which review this is. 90-day, 180-day, or one-year - each asks different questions (see Steps 2-4) and needs different evidence. Do not run all three at once by default; ask which milestone the CTO has actually reached.
2. What role type this CTO is. The book's evidence criteria shift by role: startup CTO, founder replacement CTO, growth and scale CTO, SME CTO, business-unit CTO, enterprise CTO, or fractional or interim CTO. Ask the user which lens applies - or if more than one overlay applies (for example, a startup CTO in a regulated industry), say so explicitly rather than picking one silently.
3. What the entry agreement actually says. A review has to be run against the mandate this CTO actually accepted, not a mandate invented after the fact from recent frustration. Ask the user for the original or most recently revised mandate, the hiring-bet memo, and (for a 90-day review) the first-90-days agreement. If none of these exist, say so plainly: the book is explicit that running a review without a written entry agreement invites the exact failure it warns about - the review becomes "a negotiation about history instead of a check against a promise." Offer to help reconstruct a plain-language statement of what was expected, labeled clearly as reconstructed-after-the-fact, not as the original agreement.
4. Whose input this draws on. The book wants evidence from the CTO's self-review, factual input from people who work with them, and company-side facts (did the company itself honor access, authority, budget, and commitments?) - not one executive's impression alone. Ask who else's input the user can supply.
5. What must not go into this skill. No inference about the CTO's personality, protected characteristics, mental state, or private communications - the book repeats this instruction at every review stage, and this skill holds it as a hard boundary, not a suggestion.

Steps

1. Confirm the role-specific lens

Before organizing any evidence, state which role-specific evidence applies for this review, using the book's own criteria:

• Startup CTO - learning and runway are better connected, the product is more credible, the first team or technical direction is stronger. Do not demand enterprise process.
• Founder replacement CTO - the transition is stable, the founder boundary is working, key knowledge is transferring, the new executive is respecting history without preserving shadow authority.
• Growth and scale CTO - capacity tradeoffs between product and foundational work are explicit, cross-product escalations are falling, and new councils or standards are reducing coordination tax rather than adding to it.
• SME CTO - control of systems, vendors, risk, spending, ownership, and priorities. Do not demand an ambitious transformation brand.
• Business-unit CTO - local priorities and enterprise dependencies are clearer, and the executive can move a real decision across the matrix.
• Enterprise CTO - operating mode is clear, material portfolio and governance problems are visible, business-unit relationships are credible.
• Fractional or interim CTO - what decisions improved, what internal capability grew, whether scope fits available time, and whether dependence is increasing rather than transferring.

This lens changes what counts as good evidence at every step below - apply it throughout, not just at the end.

2. If this is the 90-day review

Organize evidence under these eight questions, exactly as the book poses them - not restated, not reordered:

1. Does the CTO understand how the business makes money and serves customers?
2. Has the CTO established credible contact with technical and operating reality?
3. Are the largest risks and constraints clearer than they were?
4. Did the CTO handle urgent decisions with judgment?
5. Are decision rights and executive relationships improving?
6. Has the CTO assessed leaders fairly and identified real gaps?
7. Is the 12-month agenda focused, funded enough to begin, and linked to business outcomes?
8. Has the CTO told the truth, including facts that complicate the hiring story?

For each question, fill in a row of this evidence table using only supplied material:

Use the book's own good/weak pairs as the calibration reference (for example: "explains customers, economics, strategy" is good evidence of business understanding; "attended executive meetings and repeated strategy language" is weak evidence of the same). Explicitly flag a dramatic first quarter (reorganizations, platform announcements, vendor selections, rewrite programs) as something to examine, not celebrate - the book calls this a possible warning sign, not automatically bad.

Close by stating which of the book's four outcomes the evidence in the table above most supports, and why - citing the specific rows that carry the weight of the call, not a general impression:

• On mandate: continue with clarified priorities.
• On mandate with support: address a named condition (authority, team, budget, peer agreement).
• Mandate changed: rewrite the agreement because the original diagnosis was wrong on something that matters.
• Serious concern: define evidence, immediate protection, support, and a short review period.

If two outcomes are both genuinely defensible on the evidence supplied

• not just theoretically possible, but actually close - name both, state the reasoning for each, and state exactly what evidence or conversation would resolve which one is right. Do not manufacture a single answer out of a real tie; do not manufacture a tie out of evidence that actually points one way to avoid committing to a read.

3. If this is the 180-day review

The center of this review is changed decisions, not activity. Organize:

• Subtraction evidence - what has the company stopped doing because the evidence did not support it? The book calls a CTO's tenure with no subtractions "accumulating false alpha" - name this pattern explicitly if the supplied evidence shows only additions (new councils, platforms, programs) and no stops.
• 12-month agenda review, item by item: is the business need still valid? Has an accountable owner accepted it? Is capacity actually allocated? What changed because of the work? What was learned? What should stop, continue, narrow, or accelerate? Avoid percentage-complete reporting - flag it if the user's material relies on it, since a program "70 percent complete" can still have no path to adoption.
• Leadership and organization evidence - is the CTO setting clear outcomes with real authority, building a technical leadership network rather than a personal court, handling underperformance with fairness and speed, retaining credible people who disagree, recruiting for future work rather than loyalty, and reducing key-person dependency (including dependence on the CTO personally)?
• One traced mechanism - pick one new or changed mechanism (architecture decisions, reliability review, product-platform capacity, vendor governance, security-by-design, portfolio investment) and trace three real decisions through it: did it improve the decision, add delay, get bypassed, produce evidence, or need to exist at all? This is more informative than reviewing a mechanism's slides - insist on real, traced decisions, not a summary.
• Role-specific evidence and warning signs, using the lens from Step 1 (for example, for a founder replacement: new authority working and knowledge transferring is the evidence to look for; shadow decisions and "public unity, private bypassing" is the warning sign).
• Company-side evidence - did the CEO resolve cross-executive conflicts, did product and finance fund agreed work, did the board support necessary risk decisions? Do not mark the CTO down for an outcome the company itself repeatedly chose not to fund; do note whether the CTO made that consequence visible early with credible alternatives.

Close by stating a read on trajectory - improving, flat, or deteriorating against the mandate - citing the specific evidence above that carries the call, and naming what would change that read. If the subtraction evidence, the traced mechanism, and the company-side evidence point in different directions, say so explicitly rather than averaging them into a falsely tidy summary.

4. If this is the one-year review

Organize against the book's balanced eight-dimension scorecard:

For every claimed result, record: baseline, current evidence, possible CTO contribution, other plausible explanations, and any cost shifted elsewhere (a result that looks good because risk or cost moved to another team or a future quarter is not a clean result). Then run two explicit causation checks, verbatim from the book, and record honest answers to both rather than picking the more flattering one:

• "Which capability would disappear if the CTO left tomorrow?"
• "Which capability exists because the organization changed, not because the CTO remains personally involved?" (The book calls the second answer stronger evidence of real scale-building.)

Close with the original hiring-bet memo, unaltered, next to current evidence - which assumptions proved correct, which risks appeared, what support was actually provided, what changed in the company. This compares the reasoning that led to the hire against what happened, not a re-litigation of the hire using hindsight. State plainly whether the case for the hire has held up, weakened, or strengthened on that comparison, and why.

5. Assemble the review pack, and a stated recommendation

Regardless of which review this is, the final handoff is an evidence pack plus a recommendation with its reasoning shown - never an evidence pack with no read on what it adds up to, and never a bare verdict with the reasoning stripped out. If the evidence genuinely supports more than one reading, present the live options with their own reasoning rather than force one; if it's too thin to support any recommendation, say that plainly and name what's missing. Either way, the recommendation is a starting point for the actual review conversation with the CTO and the people who work with them, not a replacement for it - say so explicitly when handing it over.

Organizing the output

Hand the user back, clearly separated:

1. The role-specific lens used, stated explicitly.
2. The evidence table(s) for the applicable review (90/180/365), filled in only from supplied material, with gaps marked as gaps, not guessed.
3. Company-side findings - what the company itself did or did not honor.
4. For a 90-day review: which of the four outcomes the evidence most supports, with reasoning (or the live options, if genuinely tied). For a 180-day review: the subtraction list, agenda review, traced-mechanism findings, and the trajectory read. For a one-year review: the eight-dimension table, the two causation-check answers, the hiring-bet comparison, and the stated read on whether the case for the hire held up.
5. The reasoning behind the recommendation, tied to specific rows in the evidence above, not a general impression - this is what lets the human reviewers agree, disagree, or update it with what they know that this skill doesn't.
6. Open discussion questions for the actual review conversation - what the recommendation doesn't settle, not a rehash of what it does.

What this skill does not do - check before calling it done

Before telling the user this is finished, reread the entire pack and confirm it does not, anywhere:

• State a recommendation that isn't traceable to specific evidence in the pack - every claim needs a cited row, not an impression.
• Convert the evidence into a numeric score or grade standing in for the reasoning - the recommendation has to be readable as an argument, not a number.
• Treat "needs more time" as automatically acceptable, or treat ordinary uncertainty as automatically a failure - state which one the evidence actually shows, and say so if it's genuinely unclear which.
• Infer the CTO's personality, motives, or protected characteristics from anything supplied.
• Present the recommendation as final - it is an input to the conversation the human reviewers still have to have, not a substitute for it.

This is the book's own core failure mode for a review done badly: a review that quietly becomes "a negotiation about history," or a recommendation asserted without the evidence that would let someone push back on it. If any output reads like a conclusion floating free of the evidence that supports it, the fix is the same every time - tie it back to specific rows in the pack, or drop it and say the evidence doesn't settle it yet.