---
name: cto-first-90-days-entry-plan
description: Use this skill when the user wants to plan the acceptance-to-day-90 onboarding of an incoming CTO (or comparable technology executive) - building the entry brief, a bounded first-month learning plan, a day-30 mandate check, and a day-90 assessment structure with a 12-month agenda skeleton, including a bucketed recommendation set (act now / commit / investigate / accept) wherever the user's material actually supports one. Triggers on requests like "help us onboard our new CTO," "build a first-90-days plan for our incoming CTO," "what should our new CTO's entry brief cover," or "structure our new CTO's first-quarter assessment." Structures the onboarding process and states recommendations the supplied evidence supports; leaves personnel assessment and the incoming CTO's own agenda calls to their direct observation, which this skill has no access to.
---

# Build the CTO's First-90-Days Entry Plan
This skill is Labor as Code™ for "Spend the First 90 Days Learning Before You Commit," the onboarding
chapter of *The CTO You Actually Need*. Read that chapter for the
reasoning - this skill only executes the mechanics of building an entry
brief, a bounded first-month plan, and a day-90 assessment structure. It
requires the finished mandate, decision-rights map, and (if this
company ran one) the hiring-bet memo and known-risk plan as inputs; if
those do not exist yet, say so and offer to help reconstruct a
plain-language statement of what was promised before proceeding, rather
than inventing an entry plan against no real agreement.

**This skill structures the company's side of onboarding - the entry
brief, the learning plan, the review checkpoints. It does not write the
incoming CTO's actual 12-month agenda, assess named leaders on the
CTO's behalf, or decide any of the "act now" calls a real assessment
requires.** Those require the incoming CTO's own direct observation of
the company - something this skill cannot substitute for. Where the
book calls for the CTO's own judgment (which leaders are effective,
which mechanism to build, what to stop), this skill provides the
structure to organize that judgment once the CTO has actually formed
it, not a stand-in for forming it.

## Before running

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

1. **Who this plan is for.** Is the user the company (CEO, board,
   hiring team) preparing to onboard someone, or the incoming CTO
   themselves preparing their own entry? The entry brief content is the
   same either way, but who owns each action differs - be explicit
   about which seat the user is asking from.
2. **What was actually promised.** Pull the final mandate, hiring-bet
   memo, known-risk plan, and any commitments made during negotiation
   (a promised hire, board access, a founder boundary). The book is
   explicit that concealing or forgetting these until after arrival
   selects for distrust, not smooth onboarding.
3. **Whether this is a replacement, a founding-CTO transition, or an
   interim/fractional start.** Each needs different framing in the
   entry brief (a replacement needs outgoing-leader transition
   agreements; a founder transition needs the founder's future role
   settled and communicated *before* the incoming executive arrives; an
   interim/fractional start needs the charter distributed so employees
   know what authority actually exists).
4. **What must not be decided here.** Any people decision (a
   reorganization, an assessment of a named leader, a termination) is
   explicitly out of scope for this skill - it belongs to the CTO's own
   direct observation plus the company's HR process, not a plan built
   in advance of arrival.

## Steps

### 1. Close the search honestly

Before drafting the entry brief, confirm with the user what the
incoming CTO will be told, and when:

- The final mandate, decision rights, hiring-bet memo, known risks, and
  material commitments made during negotiation.
- Which items remain assumptions rather than settled facts.
- Anything the company's view changed on since the offer - the book is
  explicit this must be said before arrival, not discovered later.
- For a replacement: the communication and transition agreement with
  the outgoing leader.
- For a founding-CTO transition: the founder's settled future role and
  boundaries, agreed *before* presenting the incoming executive as the
  solution.
- For an interim or fractional appointment: the charter, distributed so
  employees know what authority actually exists.

### 2. Build the entry brief

Assemble, with the user, an entry brief covering exactly these areas -
curated, not a document dump, with a named person who can explain each
one:

- Business strategy and financial context appropriate to the role.
- Product and customer priorities.
- Organization and leadership profiles.
- Technology estate and major dependencies.
- Recent incidents, audits, customer escalations, and known risks.
- Active commitments, contracts, and transformation programs.
- Board calendar and upcoming decisions.
- A map of the people the role depends on.
- Decisions that can wait, and decisions that cannot.

Flag to the user if what they are assembling is closer to "a document
repository" than a curated brief - the book calls out drowning the
incoming executive in material as a real failure mode, not a
theoretical one.

### 3. Structure the first month as learning with limited action

Lay out the first 30 days using the book's own week-by-week shape as a
planning skeleton, not a rigid script:

| Period | Primary work | Company/CEO responsibility | Evidence of a good start |
|---|---|---|---|
| Before day 1 | Access, communication, transition, entry brief | Honor commitments and resolve role ambiguity | CTO arrives knowing the mission, risks, and key relationships |
| Days 1-10 | Listening, business immersion, team contact, urgent triage | Provide context and protected time; avoid using the CTO as instant referee | Questions improve; urgent issues are contained without sweeping conclusions |
| Days 11-20 | Time deep in systems, customer and system observation, decision mapping | Introduce real conflict and tradeoffs, not only presentations | Assumptions are separated from evidence; hidden dependencies appear |
| Days 21-30 | Initial synthesis, mandate review, next assessment plan | Decide scope or authority changes promptly | Clear risk map, deferred decisions, and shared cadence |

Reasonable first-month **outputs** to plan for, explicitly, rather than
demanding a finished strategy:

- Confirmed or revised mandate assumptions.
- A summary of what the CTO heard from executives, the team, and
  customers.
- An initial technology and organizational risk map.
- A list of urgent actions and decisions deliberately deferred.
- A communication cadence with the CEO and peers.
- A plan for the deeper assessment through day 90.

State plainly to the user if they are asking this plan to demand a
complete strategy inside 30 days - the book calls that a way to get
either recycled ideas or false certainty, not real learning.

### 4. Build the day-30 mandate review structure

The hiring process ran on limited information; expect the incoming CTO
to challenge the mandate after real learning. Structure this as a
three-column check, not a free-form conversation:

| Original mandate assumption | Confirmed / contradicted / still unknown | Evidence |
|---|---|---|

Any material scope or authority change that surfaces here belongs to
the CEO and relevant executives to decide - this skill organizes the
check; it does not adjudicate the change.

### 5. Structure urgent-decision handling

Some incoming CTOs inherit a release, incident, vendor renewal, security
finding, or people decision that cannot wait for the 90-day assessment.
For any such item the user names, build a fast decision record rather
than letting it get folded silently into "day one impressions":

- What must be decided, by when?
- What evidence exists?
- What would be reversible?
- Who held responsibility before the CTO arrived?
- Which risk is accepted by acting, and which by waiting?
- Who makes the final call?

Once those fields are filled in from the user's actual material, state
which option (act now, or wait for more evidence) the record's own
evidence favors, and why - reversibility and the cost of waiting are
usually the deciding factors, so name which one is driving the lean
here. Where the evidence is genuinely thin or cuts both ways, say so
instead of forcing a lean. Flag explicitly: the incoming CTO should not
become the retroactive owner of conditions the company created before
they arrived. The executive can own the *next* decision - this skill's
lean informs that decision, it does not make it for them.

### 6. Structure the bounded day-90 assessment

Build the assessment as a findings table, covering only what the user's
material actually supports:

| Finding | Evidence | Business consequence | Urgency | Current owner | Next decision |
|---|---|---|---|---|---|

Cover, as categories: business and product strategy; customer promises
and recurring pain; the delivery system and work in progress;
reliability, security, resilience, safety, and compliance as
applicable; architecture, data, infrastructure, hardware, and vendors;
cost and investment; organization, leadership, talent, and key-person
dependency; decision rights, incentives, and governance; and the
technical options the next stage requires.

Group any recommendations that emerge into four buckets - **act now**,
**commit within 12 months**, **investigate**, **consciously accept** -
rather than one undifferentiated list. Avoid a single maturity score
that compresses different risks into one number; the book is explicit
this hides exactly the few constraints that should shape the agenda.

**Leadership assessment is explicitly out of this skill's scope.**
Where the assessment touches "is this leader effective, does this leader
need a changed role," record only that this category exists and must be
formed by the CTO's own direct observation (meeting people, observing
work, reviewing outcomes, understanding constraints) - never let this
skill draft a judgment about a named person standing in for that
observation.

### 7. Build the 12-month agenda skeleton and operating cadence

Help the user structure - not author - the shape of a 12-month agenda:
a small number of outcomes (the book says five or fewer), explicit
tradeoffs, owners, and leading evidence, integrated across product,
delivery, risk, cost, talent, and architecture. Require an explicit
stop-doing list alongside it - an agenda that only adds work is, in the
book's own words, not a plan.

Lay out the recurring mechanisms a day-90 operating cadence should
include, each with a decision purpose, inputs, an owner, and an exit
rule (not just a standing meeting): CEO-CTO one-to-one; product and
technology tradeoff review; reliability and risk review; investment and
capacity decisions; senior technology leadership forum; board or
executive technology reporting; incident and decision learning.

## Organizing the output

Hand the user back, clearly separated:

1. **Pre-arrival closure checklist** - what gets communicated to the
   incoming CTO, and when.
2. **Curated entry brief outline**, with a named explainer per section.
3. **First-30-days plan**, in the period/work/responsibility/evidence
   table shape, plus the explicit output list.
4. **Day-30 mandate review table** (confirmed / contradicted / still
   unknown). Items 3 and 4, with the plan for assessment through day
   90, make up the first-90-days agreement the 90-day review checks
   against; the CEO and the CTO both agree to it in writing.
5. **Urgent-decision fast record**, per item, if any surfaced.
6. **Day-90 assessment findings table**, grouped into the four action
   buckets, with the leadership-assessment category explicitly marked
   as the CTO's own judgment to form, not this skill's to fill in.
7. **12-month agenda skeleton and operating-cadence table**, with the
   stop-doing list required alongside it.

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

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

- Assess a named leader's performance or fitness - this stays out of
  scope for a real reason, not house caution: forming that judgment
  requires the CTO's own direct observation of the person's work, which
  this skill has no access to and cannot substitute for with inference.
- Invent technical findings, urgent-decision leans, or day-90 bucket
  placements the user's material does not actually support - every
  recommendation this skill states (the urgent-decision lean in Step 5,
  the act-now/commit/investigate/accept bucketing in Step 6) has to
  trace to evidence the user actually supplied, not a plausible guess.
- Demand or imply a finished strategy inside the first 30 days.
- Execute an "act now" call on a real decision (a reorganization, a
  vendor cut, a release) - bucketing a finding as act-now is this
  skill's job when the evidence supports it; actually making the call
  is the CTO's, once they hold the authority and the direct observation
  this skill cannot supply.

The book's own core warning for this stretch is a CTO locking the
company into assumptions before evidence exists, or a company demanding
premature certainty from someone who has been there three weeks. This
skill's structure exists to prevent both - reread the plan once more
and confirm every stated recommendation traces to real evidence, and
that nothing is asserted about a named person's performance that only
direct observation could support.