Build the CTO's First-90-Days Entry Plan

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…

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:

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:

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:

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.