Skip to content

Worksheet — Leadership charter

Phase: 0 — Readiness Duration: 60 minutes (can run long in enterprises; do not skip). Primary output: Signed one-page charter + Decision Record.

Why this meeting matters

Programs that skip this meeting discover six months later that nobody knows who is empowered to stop the program, what "success" looks like, or which board member is accountable when something goes wrong. The charter puts those answers in writing before the pilot starts.

The meeting is intentionally short so executives will actually hold it. It is not the right place to debate tool selection, specific policies, or training plans. Those are in other worksheets.

Pre-work

Who to invite

Sizing guide

  • Small (< 50): CEO or founder + senior engineer + one ops/legal contact. 45 minutes.
  • Mid (50–500): CTO/VP Eng + CISO + Head of Legal or delegate + one BU leader.
  • Enterprise (500+): CTO/CIO + CISO + CPO + Head of Legal + Head of Risk + two BU leaders. Consider Board sub-committee briefing separately.
  • Regulated: add Head of Compliance. In some jurisdictions, involve Risk Committee chair.

Required in the room (or with a delegate who has sign-off authority):

  • An executive sponsor candidate: one named person who will own the program end-to-end.
  • Engineering leadership: the person who will be asked to deliver.
  • Security leadership: CISO or delegate.
  • Legal representation: for any program that will touch customer data, IP, or contracts.

Optional but useful:

  • CPO / Head of Data, if you hold personal data at scale.
  • CFO or delegate, for meaningful budget conversations.
  • Comms lead, so public-facing messaging is considered early.

Materials to circulate 48 hours in advance

Send a one-page pre-read containing:

  1. The problem statement: why are we considering AI-assisted development now? (Competitive pressure, board question, engineer demand, cost, productivity.)
  2. A summary of the evidence base: two paragraphs using the evidence pack. Include at least one study showing a gain and one showing a cost. Leadership must see both.
  3. A draft of the charter itself, so the meeting is editing, not drafting. See the template below.
  4. The risk matrix summary, so "which workloads are in scope" is grounded.

Agenda (60 minutes)

Time Topic Owner
0–5 Purpose and ground rules. Confirm everyone has read the pre-read. Facilitator
5–15 What does success look like? Pin three concrete outcomes by which the program will be judged 12 months from now. Sponsor candidate
15–25 What is explicitly out of scope? (Workloads, data classes, roles, geographies.) CISO + Legal
25–35 What are the stop conditions? Specific triggers that would cause a pause or rollback. CISO + Sponsor
35–45 Who decides what, and on what cadence? Decision rights and review rhythm. Sponsor + Facilitator
45–55 Draft the charter live. Fill in the template on screen. Scribe
55–60 Sign, or name the blocker. If nobody will sign, name what is missing and when it will be resolved. Sponsor

Discussion prompts

Use these to drive the first three agenda blocks. Don't rush them. Fast charter meetings produce charters that don't survive contact with reality.

Success prompts

  • In 12 months, what is different about how we ship software that will make this program visibly worthwhile?
  • What outcome would make the board or the CEO say "this was the right call"? What outcome would make them reverse it?
  • Are we framing success in terms of developer productivity, product quality, time to market, hiring, or something else? Pick primary and secondary.
  • If we achieve the primary outcome but score poorly on the secondary, is that still success?

Scope prompts

  • Which business units are in? Which are explicitly out for now?
  • Which data classes (customer PII, regulated health data, payment data, source code of crown-jewel systems) must never be sent to any external AI service?
  • Which roles are in scope? (Engineers only? QA? Support? Data? Analysts? Product?)
  • Are we taking a position on agents (AI systems that act, not just advise) at this point, or deferring?

Stop-condition prompts

  • What incident would cause us to pause the program immediately? (Data leak? Production outage with AI root cause? Regulator letter?)
  • What metric movement would cause us to pause? (Change-failure rate +25% for two consecutive months? MTTR +50%?)
  • What external event would cause us to revisit? (Major vendor acquisition, regulatory action against the chosen vendor, sector rule change?)
  • Who has authority to pull the stop-cord, and how fast?

Decision-rights prompts

  • Who approves tool additions and removals?
  • Who approves AUP changes?
  • Who approves training plan changes?
  • Who receives the monthly KPI report, and what happens when it arrives?
  • Who briefs the board, and how often?

The charter template

Copy the rendered template below into your wiki, ADR repo, or governance page and fill in the bracketed placeholders. A raw-markdown version is in the second tab for direct paste.

AI-Assisted Development — Leadership Charter

Version: 1.0 Effective date: YYYY-MM-DD Sponsor: role and name Review cadence: monthly / quarterly

Purpose. In one paragraph: why this company is adopting AI-assisted development, and the problem it is intended to address.

Success criteria.

  • Primary: one measurable outcome with a target and date
  • Secondary: up to two more

Scope.

  • In: business units, teams, roles, workloads
  • Out: explicit exclusions

Stop conditions.

  • event or metric 1
  • event or metric 2
  • event or metric 3

Decision rights.

Decision Owner
Tool additions / removals
AUP changes
Training plan changes
Incident response (AI-adjacent)
Program pause / stop

Governance cadence.

  • Monthly: who, what
  • Quarterly: who, what
  • Annual: who, what

Public commitments. The company will / will not make public commitments about AI use until date / condition.

Signatures. Exec sponsor, CISO, Legal, others as required.

# AI-Assisted Development — Leadership Charter

**Version:** 1.0
**Effective date:** YYYY-MM-DD
**Sponsor:** <role and name>
**Review cadence:** <monthly / quarterly>

## Purpose

In one paragraph: why this company is adopting AI-assisted development,
and the problem it is intended to address.

## Success criteria

- Primary: <one measurable outcome with a target and date>
- Secondary: <up to two more>

## Scope

- In: <business units, teams, roles, workloads>
- Out: <explicit exclusions>

## Stop conditions

- <event or metric 1>
- <event or metric 2>
- <event or metric 3>

## Decision rights

| Decision | Owner |
|---|---|
| Tool additions/removals | |
| AUP changes | |
| Training plan changes | |
| Incident response (AI-adjacent) | |
| Program pause/stop | |

## Governance cadence

- Monthly: <who, what>
- Quarterly: <who, what>
- Annual: <who, what>

## Public commitments

The company will / will not make public commitments about AI use until
<date / condition>.

## Signatures

<Exec sponsor, CISO, Legal, others as required>

Outputs

At the end of the session, you must leave with:

  1. Completed charter (1 page).
  2. Decision Record capturing the meeting (see template), tagged phase-0 and governance.
  3. Named exec sponsor with single-point accountability.
  4. Calendar invite for the next check-in (typically 30 days).
  5. Owner and date for the interim AUP (next worksheet).

Follow-ups

  • Within 48 hours: publish the charter to a durable location and acknowledge it in an all-hands update (or equivalent).
  • Within 7 days: run the AUP drafting workshop.
  • Within 14 days: run the Risk classification workshop.
  • Within 30 days: sponsor check-in.

Facilitator tips

  • Resist the urge to pick tools in this meeting. "Which is better, Copilot or Cursor?" is not a leadership charter question. If it comes up, note it and defer to the Vendor selection worksheet.
  • Push back on "we'll figure out success later". If the room can't name success in one hour, that is a finding. Document it as a DR with status proposed and reconvene in 7 days.
  • Make stop conditions concrete. "Major incident" is not a stop condition. "Any customer data written to a public LLM endpoint" is.
  • Read back the sign-offs. Before closing, state aloud who is accountable for what. Public statement beats silent nod.

Anti-patterns

Don't

  • Don't leave without a named sponsor. A charter owned by a committee is owned by no one.
  • Don't allow "success = high adoption" as the only metric. Adoption is an input; outcomes are what matter.
  • Don't treat the charter as permanent. Review cadence is part of the charter for a reason.
  • Don't over-draft the charter. If it exceeds two pages, cut. What doesn't fit becomes the AUP, the standard, or the runbook.

Next