Define the CTO Mandate and Decision Rights

Use this skill when the user wants to define what a CTO role actually is before hiring, evaluating, or restructuring one - building a decision-rights map and a written CTO mandate instead of a generic job description, and a stated recommendation on whether…

Download SKILL.md

This skill is Labor as Code™ for "Define the CTO Job by the Decisions It Owns" and "Diagnose the Company and Write the Mandate," the first two chapters of The CTO You Actually Need. Read those chapters for the reasoning behind every step below. This skill only executes the method the book teaches for turning a vague sense that "we need a CTO" into a written, decision-rights-based mandate a real search can run against. It does not decide anything the book leaves to the company's own executives: whether the company needs a CTO at all, what authority any given decision carries, and which outcomes matter most are always the user's calls, never this skill's.

This skill produces a document and a stated recommendation, both traceable to the user's own evidence. It states whether the Context Pack and the symptom-to-cause table actually support a CTO hire, or support a different fix (a VP Engineering, a product operating change, a non-technical fix the company has been avoiding) instead, or - when the evidence genuinely cuts both ways - lays out the live options with what would resolve each. It never assigns a specific person to a role, and it never manufactures a resolution to a disagreement between executives that their own material doesn't settle; there, it states each side's position and its supporting evidence rather than picking a winner neither side's own facts decided. Where the book calls for a decision only a named human can make and the user's material simply doesn't say - not "the skill declines to weigh in," but "the input to weigh isn't there yet" - this skill inserts an explicit open question instead of guessing.

Before running

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

What triggered this. A CTO search rarely starts from a clean diagnosis; it starts from an event (a missed release, a security gap, a founding CTO struggling to scale, a stalled transformation, investor pressure). Ask what the triggering event actually was. If the user cannot name one, ask what changed recently that made technology leadership feel urgent.
Who is in the room for this. The book insists the mandate be an agreement among the executives who will live with it, not a solo document. Ask who else needs to weigh in before this mandate is final (CEO, other founders, board, CFO, current technology leader) - this skill can draft, but cannot substitute for that conversation.
What material the user can actually supply. This method depends on real inputs, not invention: an org chart, a list of the ten or so technology decisions that have caused the most delay, conflict, cost, or risk in the past year, and a short factual statement of the business's stage, model, and constraints. If the user has none of this yet, say so and help them assemble it first (see Step 1) rather than drafting a mandate from assumptions.

Steps

1. Build the Company Context Pack

Before anything else, gather the company's own facts, not a case study or a template. Ask the user to supply or dictate answers, separating facts (measured), estimates, opinions, and disagreements

do not silently smooth a disagreement into an agreed position. Cover:
Business: what the company sells, to whom, and how it makes money; what must be true for the next stage to succeed.
Stage and scale: age, revenue, funding, headcount, technology headcount, locations, growth expectations.
Technology: which products, platforms, systems, data, hardware, vendors, and infrastructure matter most, and which are customer-facing.
Current leadership: who owns product, engineering, IT, security, data, operations, and architecture today, and where the gaps or overlaps are.
Pain and opportunity: what is failing, too slow, too expensive, too risky, or strategically limiting, and what opportunity the company cannot currently pursue.
Risk: security, safety, privacy, regulatory, resilience, contractual, or reputational obligations.
Decision: why a CTO (or a role change) is being considered now, what alternatives have been considered, and who will make the final call.

End this step with an explicit list of the questions that would most change the role if answered differently - do not let those questions quietly disappear into the rest of the document.

2. Separate symptom from cause

Do not let "we need a CTO" stand in for a diagnosis. Using the triggering event and the Context Pack, build a four-column table:

Observed symptom	Possible causes	Evidence to collect	Possible hiring implication

Fill in only what the user's material actually supports. Do not mark a possible cause as confirmed without evidence behind it. Include, as a live option in every row, the possibility that a CTO is not the right answer - a VP Engineering, a product operating change, or a fix to a non-technical constraint (a sales incentive, a finance policy, a founder's informal veto) may be the real fix. State plainly whether the company is willing to change those non-technical conditions; a CTO cannot solve a business arrangement the company refuses to touch. Once the table is filled in, state which cause the evidence best supports per symptom - or, where two causes are equally well evidenced, name both and what additional fact would separate them.

3. Decide whether the problem is executive-sized

Before mapping decision rights, test the premise: would a strong head of engineering, a clear product leader, and a security adviser be able to solve this without a new executive title? Write this test down explicitly, and answer it - state plainly whether the Context Pack and symptom-to-cause table support hiring a CTO, support the lighter-weight alternative instead, or leave the case genuinely tied, and say what evidence the answer rests on. Naming the reasonable alternative first is the book's own discipline for claims of "alpha" applied to a hiring decision - do not skip it because the user already wants to hire, and do not let wanting to hire substitute for the evidence this step is supposed to test.

4. Build the decision-rights map

For each of the ten (or so) technology decisions the user supplied, determine whether a CTO would plausibly:

Own it and make the final call.
Share it with another executive.
Influence it through expertise and evidence.
Review it because risk crosses an agreed threshold.
Delegate it within a system the CTO designs.
Veto it under narrow, explicit conditions.

Build this as a table: decision, business outcome, current owner, who must contribute, time horizon, cost of delay, risk of a wrong answer, and the proposed verb above. Flag every row where accountability would exceed the authority the company appears willing to give - that mismatch is the single most common reason a CTO hire fails, and the book is explicit that it must surface before the search starts, not after the person is in the seat.

Do not silently resolve a row where the user's material is ambiguous. Insert a decision question in that row instead ("Who accepts material cyber risk above $X - unclear from supplied material") and hand the list of open questions back to the user at the end.

5. Test the role against adjacent titles

Titles hide role confusion. Before finalizing, check the proposed CTO scope against the roles it most often gets confused with - VP Engineering, CIO, CISO, CPO, chief architect, chief data/AI officer, and transformation leader. For each adjacent role that plausibly overlaps with what the user described, ask (and record the answer, not invent it):

Who owns engineering managers, staffing, performance, and delivery operations?
Who owns cross-product architecture and platform investment?
Who decides capacity between roadmap work and foundational work?
Who carries systemic reliability and cost concerns to the executive team?
Who speaks for technology with the board, customers, investors, or regulators?
Who settles disagreement between product delivery and long-term technical constraints?

Write the answer once, in the mandate, rather than leaving it as "partners closely with" - the book calls that phrase a relationship description, not a decision rule.

6. Draft the seven-part mandate

Using every table above, draft the mandate in this shape. A job description describes the role to candidates; a mandate records what the CTO owns, decides, and is measured on:

Business reason - the change or problem that makes the role necessary, in business language, not "modernize the stack."
Outcomes - three to five outcomes for the first 12-24 months. The first should protect the company's actual, evidence-backed advantage (its Native Alpha, in this imprint's terms) rather than only fix weaknesses. Each outcome needs a result and evidence, not a list of activities. Write both a weak and a stronger version of each outcome, the way the book does, so the user can see the difference.
Scope - functions, products, regions, systems, budgets, and risks in scope, and the important exclusions, named explicitly.
Decision rights - the table from Step 4, using precise verbs (inside each decision: recommend, decide, approve, fund, execute, verify, accept risk, veto; the six postures from Step 4 say where the CTO stands), never "partner with."
Relationships - the relationships that determine success, and the expected conflict in each, not only the desired harmony.
Constraints and inherited conditions - budget, debt, vendor dependence, contractual commitments, leadership gaps, founder involvement, planned financing, regulation, acquisitions, limits on changing the team. Concealing these does not improve the candidate pool; it selects for people who don't investigate.
Evolution - how the role is expected to change after the first mission.

Keep the core mandate to two to four pages; put supporting maps and scorecards in an appendix rather than bloating the mandate itself. If drafting this mandate requires forty responsibilities to feel complete, say so to the user directly - that is itself a finding: priorities have not yet been chosen.

7. Turn outcomes into a scorecard skeleton

For each of the three to five outcomes in Step 6, add:

Importance to the business.
Evidence a candidate could plausibly bring from prior work.
Evidence that can be tested during hiring.
Conditions that made prior success possible elsewhere.
Risks or failure modes specific to this company.
What good progress would look like at 90, 180, and 365 days.

Do not include soft attributes like "executive presence" unless they are rewritten as an observable behavior tied to the mandate (for example: "explains uncertainty clearly," "challenges a powerful executive without losing the decision"). This scorecard skeleton is the handoff point to the cto-hiring-evidence-and-search skill, which turns it into weighted interview criteria - this skill's job ends at a usable outcome list, not a full hiring process.

Organizing the output

Hand the user back five artifacts, clearly labeled and separated so nothing gets lost in a wall of text:

Company Context Pack v1, with its unresolved-questions list intact.
Symptom-to-cause table, with the "no CTO needed" option evaluated, not omitted, and the best-supported cause per symptom stated.
Decision-rights map, with every ambiguous row flagged as an open question rather than resolved.
CTO mandate draft (the seven parts) plus the outcome-linked scorecard skeleton.
A stated recommendation: does the evidence support hiring a CTO, support the lighter-weight alternative from Step 3, or leave the case genuinely tied - with the reasoning and the specific evidence behind it, so the executives are deciding from a stated position, not a blank page.

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

This skill never states, implies, or lets a draft imply any of the following, because the book keeps every one of them a human decision that this skill's evidence cannot substitute for:

Names a specific candidate, title, or person as fitting the role - the mandate defines the role; who fills it is a different skill's job (cto-hiring-evidence-and-search).
Presents a resolved answer to a decision-rights row the user's material left genuinely ambiguous - that stays an open question in the output, not a guess dressed up as a finding.
Claims a disagreement between executives (over scope, authority, or who owns a decision) has been settled by this draft, when the executives' own material never actually settled it. The draft can and should state which side's position the company's own evidence currently favors, but a preference between people's stated positions on a question their own facts leave open is not this skill's to manufacture.
States the CTO-or-not recommendation (or any other conclusion in this skill's output) with more confidence than the underlying evidence supports - thin or conflicting material means a stated "genuinely tied" or "not enough evidence yet," not a coin-flip dressed up as a finding.

Before telling the user this is done, reread the decision-rights map and the mandate draft once more and confirm every "own" or "veto" the draft assigns is something the user's own material actually supports - an unearned decision right handed to the CTO on paper is the exact failure mode ("accountability exceeds authority the company is willing to give") the book spends two chapters warning against.