---
name: cto-mandate-and-decision-rights
description: 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 the evidence actually supports a CTO hire. Triggers on requests like "help us figure out what we actually need a CTO to do," "write a CTO mandate," "map our technology decision rights," "we're not sure if we need a CTO, CIO, or VP Engineering," or "define the CTO role before we start the search."
---

# Define the CTO Mandate and Decision Rights
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:

1. **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.
2. **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.
3. **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:

1. **Business reason** - the change or problem that makes the role
   necessary, in business language, not "modernize the stack."
2. **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.
3. **Scope** - functions, products, regions, systems, budgets, and
   risks in scope, and the important exclusions, named explicitly.
4. **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."
5. **Relationships** - the relationships that determine success, and
   the *expected conflict* in each, not only the desired harmony.
6. **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.
7. **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:

1. **Company Context Pack v1**, with its unresolved-questions list
   intact.
2. **Symptom-to-cause table**, with the "no CTO needed" option
   evaluated, not omitted, and the best-supported cause per symptom
   stated.
3. **Decision-rights map**, with every ambiguous row flagged as an open
   question rather than resolved.
4. **CTO mandate draft** (the seven parts) plus the outcome-linked
   scorecard skeleton.
5. **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.