--- name: cto-hiring-evidence-and-search description: Use this skill when the user wants to run a structured, evidence-based CTO (or comparable technology-executive) search - building a weighted scorecard, interview guides, a work-sample case, a reference plan, an evidence summary per candidate, and a stated hiring-bet recommendation with its reasoning. Triggers on requests like "help us build a CTO hiring scorecard," "design interview questions for our CTO candidates," "organize our reference-check evidence," "write a hiring-bet memo for this candidate," or "set up our CTO search process." States which candidate the evidence best supports and why, or names the case as genuinely tied between finalists; the named decision owner still holds final hiring authority. --- # Run an Evidence-Based CTO Search This skill is Labor as Code™ for "Build the Search and the Candidate Pool" and "Interview, Verify, and Decide," the two search-and-selection chapters of *The CTO You Actually Need*. Read those chapters for the reasoning - this skill only executes the mechanics of turning a mandate into a consistent, evidence-driven search. It requires a finished mandate and scorecard skeleton as input; if the user has not yet defined what the CTO role actually is, run the `cto-mandate-and-decision-rights` skill first; this skill does not invent a mandate of its own. **This is the load-bearing rule for this whole skill: every output traces to cited evidence, and the final output states a recommendation with its reasoning.** The scorecard, the interview guides, the evidence summaries, and the reference synthesis all lay out what the evidence shows, what it does not show, and what questions remain open - that groundwork is what makes the recommendation earned rather than guessed. The hiring-bet memo then closes the loop: state which candidate the evidence best supports, or, where two finalists are genuinely close, say so and lay out both cases side by side rather than forcing a single name past what the evidence bears. Either way, name the decision owner (see below) as the person who makes it final - this skill's recommendation is a considered lean, built from evidence with its reasoning shown, not the hiring decision itself. Never round mixed or thin evidence up into unwarranted confidence in one candidate; say plainly when the evidence doesn't yet support a lean at all. ## Before running Confirm with the user, in plain conversation, before drafting anything: 1. **The mandate exists.** This skill needs the finished mandate and outcome-linked scorecard skeleton (from `cto-mandate-and-decision-rights` or equivalent). A scorecard built without a mandate behind it just measures whatever the interviewers already prefer. 2. **Who the decision owner is.** One named person owns the hiring decision (usually the CEO, unit president, or board, depending on governance). This skill can support a hiring committee's process, but never substitutes for that named owner, and should not be asked to. 3. **What candidate material may go into an AI tool.** The book is explicit: no confidential source code, security findings, personal candidate information, medical information, protected financial information, or legally privileged material without organizational approval. Confirm with the user what may be pasted in versus what must stay out, and default to anonymized candidate IDs rather than names throughout. 4. **Legal/HR review is separate from this skill.** Interview design, screening criteria, and reference practice need review by the user's own HR and legal advisers for lawfulness, consistency, and accessibility. This skill drafts material for that review; it is not a substitute for it. ## Steps ### 1. Turn the mandate into a weighted scorecard Choose five to seven criteria tied directly to the mandate's outcomes - more than seven lets every candidate be justified somewhere. For each criterion, define: | Criterion | Weight | Evidence sought | Weak proxy to avoid | |---|---|---|---| Weights should reflect the actual mandate (a founding-builder role weights product/technical creation heavier; an enterprise role weights influence and federated operating judgment heavier) - ask the user which outcomes matter most rather than defaulting to an even split or copying the book's own example weights verbatim. ### 2. Define the evidence scale and use it consistently Every candidate gets evaluated on the same five-level scale, recorded explicitly rather than left implicit in an interviewer's impression: 1. **Claim** - candidate says they can do it. 2. **Example** - candidate describes a relevant situation. 3. **Specific evidence** - candidate explains decisions, constraints, actions, results, and lessons. 4. **Corroboration** - a reference, artifact, metric, or other participant supports the important elements. 5. **Transfer** - the interview team can explain why the evidence applies to *this* mandate and what conditions differ. A rehearsed story can be detailed without being true - detail is not the same thing as evidence level 3 or above. ### 3. Build interview guides per criterion For each scorecard criterion, draft a structured evidence interview: - Two past-work questions to open with (never a hypothetical first). - A follow-up sequence per question, testing: the business situation, what the candidate knew at the time, what remained uncertain, options considered, who disagreed and why, what the candidate personally decided or influenced, what the organization did, the result, and what evidence suggests the candidate's contribution actually mattered. - One scenario question that changes a constraint in three stages (for example: "What if the largest customer refuses?" / "What if the CISO disagrees?" / "What if the board cuts the budget by 30 percent?") to test whether the candidate updates their answer or defends the first position. - A note-taking template that separates **candidate statements**, **interviewer observations**, and **unresolved questions** into three distinct columns - this separation is what keeps a later evidence summary honest. Assign each criterion a primary interviewer and, where possible, a second source of evidence (a peer, a work sample, a reference), rather than one interviewer covering everything. ### 4. Design a work-sample case, if the mandate calls for one If the user wants a work sample, build it around a decision the CTO is likely to face *repeatedly* in this company, not the company's actual live problem (do not ask a candidate to solve something the company intends to use). Include: - A two-page candidate brief with known facts and explicit gaps - reward candidates for identifying what they need to know, not for guessing confidently. - Three new facts or constraint changes to introduce mid-discussion. - Named participants who will voice real, non-caricatured objections (product, finance, security, engineering - whoever the mandate actually involves). - A bounded time commitment (60-90 minutes plus a short pre-read is usually enough); flag to the user if the design is asking for several hours of free work, and note that paid, bounded alternatives exist. - An evidence rubric scoring framing, questions asked, tradeoffs surfaced, technical contact, decision ownership versus delegation, communication, and whether the candidate updates their view when a constraint changes. ### 5. Build the reference plan from evidence gaps, not a supporter list At the end of interviews, list (with the user, from actual interview notes): - Claims essential to the mandate. - Conditions that made the candidate successful elsewhere. - Failures or conflicts that need more context. - Leadership transitions the candidate says they managed. - Areas where evidence is still thin. Turn each into a specific reference question, matched to the reference relationship best able to answer it (manager, peer, direct report, product partner, customer, board member, successor - not just whoever the candidate offers first). Ask for observed behavior, authority, and result, not a character reference. Record the conditions surrounding each favorable reference (strong VP Engineering already in place, abundant capital, board air cover, mature platform) so the user can judge whether those conditions exist at their own company. ### 6. Organize evidence per candidate, without concluding For each candidate (by anonymized ID), produce an evidence summary organized into exactly these four categories, sourced only from supplied evidence: - **Demonstrated strength** - **Acceptable with support** - **Unresolved risk** - **Critical failure** Label every inference as inference, distinct from cited evidence. Do **not** total a numeric score - the five-level evidence scale and the four-category summary are not additive, and collapsing them into one number hides exactly the distinctions (claim versus corroboration, demonstrated strength versus acceptable-with-support) that make the evidence worth reading. Once every candidate's summary is built, add a short cross-candidate synthesis: which candidate's evidence is strongest against the mandate's own weighted criteria, where the gap between candidates is real versus where it's an artifact of uneven interview coverage, and whether any candidate has a critical failure that should remove them from contention regardless of other strengths. ### 7. Draft the hiring-bet memo, filled in with the best-supported case For each serious finalist, draft the book's own hiring-bet template as the strongest honest case *for* that candidate and the strongest honest case *against* them, using this shape: ``` We are choosing [candidate] because we believe [evidence-backed strengths] will produce [mandate outcomes] in our conditions. The reasonable alternative to this hire is [alternative], and we expect this appointment to outperform it by [observable result]. The main risks are [risks]. We will reduce them through [support, authority, checkpoints, or evidence]. We would change our view if [signals]. ``` Then close with a filled-in recommendation paragraph: name the candidate the evidence best supports, cite the specific evidence (level 3 or above) that carries the most weight against the mandate's weighted criteria, and state plainly what would change the recommendation. Where two finalists are genuinely close on the actual evidence - not just on how each interviewer felt - present both filled-in cases as live options rather than picking one to satisfy the template, and say explicitly what additional evidence (a specific reference, a specific work-sample follow-up) would resolve the tie. The decision owner reads a stated recommendation with its reasoning shown, not a blank to fill in themselves - but the memo's own line still holds as the check on the reasoning: if the case for a candidate can't be written honestly from the cited evidence, that is itself the finding, and the recommendation should say so rather than assert a preference the evidence doesn't support. The named decision owner makes the hire; this skill's job stops at giving them the best-reasoned recommendation the evidence supports. ## Organizing the output Hand the user back, clearly separated: 1. **Weighted scorecard** (criteria, weights, evidence sought, weak proxies). 2. **Interview guide set**, one per criterion, with the note-taking template. 3. **Work-sample packet**, if built, with its evidence rubric. 4. **Reference plan**, mapped from evidence gaps to specific questions and reference relationships. 5. **Per-candidate evidence summaries** (four categories, plus the cross-candidate synthesis from Step 6). 6. **Hiring-bet memo** per finalist (for-case and against-case), with a filled-in recommendation naming the best-supported candidate and its reasoning - or, where the evidence is genuinely tied, both cases presented as live options with what would resolve the tie. ## What this skill does not do - check before calling it done Before telling the user this is finished, reread every output and confirm none of it: - States a recommendation the cited evidence doesn't actually support - every claim behind the recommendation traces to a specific piece of evidence at level 3 or above, not to interviewer impression. - Makes the hiring decision itself, or implies the decision owner's sign-off is a formality - the recommendation is a considered lean for the named decision owner to accept, question, or override, not a fait accompli. - Infers a candidate's identity, personality, suitability, or protected characteristics from a name, photo, school, or writing style. - Treats "mixed feedback" from references as resolved by averaging - conflicting reference accounts stay conflicting, with the conditions behind each named and factored into the recommendation's reasoning, not smoothed into a false consensus. If any output crosses one of these lines, the fix is the same every time: cut the claim that outruns the evidence, and either replace it with what the evidence actually supports or say plainly that the evidence doesn't yet support a lean.