Transition Guide — Managers

Operational Policy — Managers

This document applies the principles of the AI Execution Standards to managing the human transformation. The same rigor required to delegate work to AI is required to delegate the transformation to your team.

The operating principle is the same as the Universal Translation Rule: replace "the manager requests change" with "the manager specifies the transformation → the team executes it."

1. Guiding Principle

A manager is the Spec Owner of their team's transformation.

Any transformation assigned to a team must be executable without oversight from leadership.

If your team needs leadership to step in to understand what's expected of them, your specification is insufficient.

2. Mandatory Work Layers

Before delegating the transformation to your team, you must complete all four layers.

Layer 1 — Personal Competence (prerequisite)

You must:

Personally operate at Level 2 minimum
Use AI in your daily management work (decision preparation, synthesis, analysis)
Lead by example, not just by directive

Minimum bar: You can show 3 personal workflows where AI is integrated.

A team's ceiling is its manager. If you're Level 1, your team will stay there.

Layer 2 — Team Context Mapping

Before redesigning, you must understand the current state. For each role on your team, document:

Actual tasks (not the job description — what the person really does)
Time spent per task category
Dependencies with other roles or teams
Tools used
Friction points and bottlenecks

Requirement: No transition plan is acceptable without this mapping.

Layer 3 — Intent Definition

For each role, you must define:

What Level 2 concretely means for that role (not the generic definition — the role-specific version)
Which workflows must change first (objective hierarchy)
What the employee can decide on their own vs what they must escalate
Authorized trade-offs (e.g., speed vs quality during the transition)

No transformation can start without intent defined per role.

Layer 4 — Transition Specification (highest standard)

Your transition plan is a specification, not a narrative. For each role, it contains:

Current state (Level 1 — observed behaviors)
Target state (Level 2 — expected behaviors, with acceptance criteria)
Identified gap
Redesigned workflows (before/after)
Systems or automations to implement
Success metrics
Timeline (30/60/90 days)
Failure conditions

Rule: If success cannot be verified objectively, the plan isn't ready.

2b. Specification Primitives (skills to develop)

A transformation specification is built from five primitives. Each is a distinct skill.

Primitive 1 — Honest Role Description

Describe the role as it actually operates — not the job description, not what you wish it were. Surface hidden assumptions. Identify invisible work.

Exercise: For each member of your team, answer: "If this person disappeared, what would stop? What could be automated?"

Primitive 2 — Acceptance Criteria per Role

Define what "Level 2 achieved" means for each role in a way that an independent observer can verify. If you can't write 3 sentences that verify Level 2 attainment for a role, you don't understand the role well enough to transform it.

Primitive 3 — Team Constraint Architecture

For your team's transformation, define:

Must — non-negotiable requirements
Must Not — forbidden actions or outcomes
Prefer — guidance when multiple valid approaches exist
Escalate — conditions where you must stop and consult leadership

Primitive 4 — Decomposition

Break the transformation into independently executable steps. Target: milestones of 2-4 weeks with clear inputs/outputs, each verifiable on its own. The 30/60/90 plan isn't decoration — it's a real decomposition.

Primitive 5 — Evaluation Design

For each role in transition, build 3-5 indicators that distinguish Level 1 from Level 2. Evaluate monthly. Results are judged by metrics, not by the appearance of effort.

3. Transition Plan Quality Rules

A valid transition plan must be:

Self-contained — Executable without the employee having to guess the intent.

Testable — An independent observer can evaluate progress.

Constrained — Must / Must Not / Prefer / Escalate rules defined.

Decomposable — Broken into independently verifiable steps.

Scoring Grid

Criterion	1 — Insufficient	3 — Acceptable	5 — Solid
Self-contained	Employee must guess what's expected	Intent is clear but some details are missing	Executable without clarification
Testable	No metrics or vague metrics	Metrics present but not all measurable	Every objective has a concrete metric
Constrained	No Must/Must Not rules	Some constraints defined	All 4 categories (Must/Must Not/Prefer/Escalate) covered
Decomposable	Monolithic plan with no milestones	Milestones present but not independently verifiable	30/60/90 with verifiable deliverables at each stage

Minimum acceptable score: 3 on every criterion. A 1 on any criterion = the plan is returned for revision.

4. Delegation Readiness Checklist

Before asking your team to deliver a transition plan, confirm:

I understand what Level 2 means for each role on my team
I can define success objectively for each role
I can list failure cases
I can describe the constraints and trade-offs
I can verify results without interpretation
I personally operate at Level 2 minimum

If any answer = no → you're not ready to delegate.

5. Evaluation Standard

Manager performance is evaluated quarterly on:

% of team at Level 2+
Number of automations deployed within the team
Measurable productivity gains (not perceived — measured)
Reduction of manual steps in workflows
Output per person

If your team isn't transforming, you haven't transformed.

6. Diagnosis: when the transformation stalls

When the transformation stalls, diagnose by layer:

Failure type	Root cause
Employee doesn't know what to do	Intent not defined (Layer 3)
Employee knows what to do but not how	Insufficient context (Layer 2)
Employee knows how but isn't doing it	Willingness or environment problem
Plan exists but isn't producing results	Deficient specification (Layer 4)
Manager says the right things but doesn't demonstrate them	Personal competence absent (Layer 1)

Fix the responsible layer. Don't re-issue the same directives.

The J-curve: expect a productivity dip

Your team's productivity will likely drop before it rises. This is documented, normal, and predictable. It's the adoption J-curve.

When you bolt an AI tool onto an existing workflow without redesigning the workflow, productivity drops — the team spends time evaluating suggestions, correcting almost-right code, and navigating between their own mental model and the agent's. The dip can last weeks.

The natural reaction is to conclude that AI doesn't work and revert to the old methods. That's exactly the trap. Organizations that stay stuck at the bottom of the J-curve are the ones that bolted AI onto their existing processes without redesigning them. Organizations that climb out are the ones that redesigned their workflows around AI capabilities.

Your role during the dip: hold the line. Don't revert to the old ways. Support your team in redesigning workflows, not in abandoning the tool.

Managing different adoption speeds

Your team won't all move at the same pace. That's normal. Plan for three cases:

Accelerators (~20% of the team) — They move fast, experiment spontaneously, and build before being asked.

Give them space and ambitious challenges
Use them as pairing partners for others
Make their work visible — it shows the rest of the team that it's possible

Progressors (~60% of the team) — They're willing but need direction, examples, and time.

This is where your specifications and support matter most
AI clinics and pairing are designed for them
Check their progress every 2 weeks — not to control, but to unblock

Stuck (~20% of the team) — They're not progressing. The layer-based diagnosis (above) tells you why.

If it's a competence block (Layers 1-3) → increase support: individual mentoring, dedicated time, concrete exercises
If it's an environment block (missing tool, unclear mandate) → escalate to leadership
If it's a refusal after sufficient support → document factually and escalate

After escalation — three possible outcomes (decided with leadership, never by the manager alone):

Reinforced support — the block is real and remediable. Invest more: intensive mentoring, temporary reassignment to a better-suited project, targeted coaching.
Reassignment — the person has valuable skills but their current role isn't compatible with the transition. Explore a role where their contribution is better aligned.
Separation — after documented support and insufficient effort. The decision takes into account the effort demonstrated, the obstacles encountered, and individual context.

The goal isn't to punish. It's to ensure every person is in a position where they can succeed — or to honestly recognize when that's no longer the case.

7. Organizational Roles

Every team transformation must have:

Spec Owner — the manager (defines the target state per role)
Context Owner — the manager (provides tools, training, time)
Evaluation Owner — leadership (validates progress and plans)

The manager holds the first two roles. The third is retained by leadership.

8. Documentation Standard

All plans and progress reports must be written as specifications.

Documents must:

State assumptions
Define terms (no jargon without definitions)
Specify expected outcomes
Include constraints
Avoid implicit knowledge

A transition plan that says "we will integrate AI into our processes" without specifying which ones, how, and how to verify, is not a plan.

9. What is NOT expected

The transformation has limits. Don't let your team:

Automate what requires human judgment — sensitive client decisions, personnel evaluations, ethical trade-offs remain human
Break a process that works to prove adoption — if a manual workflow is simple, fast, and reliable, forcing it into AI isn't transformation, it's theater
Over-AI-ify — the goal is to automate repetitive execution, not to remove humans from everything. Judgment, client relationships, and strategic creativity remain human skills
Sacrifice quality for speed — an AI workflow that produces mediocre content faster isn't a gain

The rule: if AI improves the outcome or frees up time for higher-value work, it's a good transformation. Otherwise, it's empty optimization.

10. Pitfalls to Avoid

The most common mistakes in this type of transformation:

Asking your team to "use AI more" without specifying in which workflows — vague input produces vague output
Evaluating on AI activity (number of prompts, hours spent) instead of results — that rewards theater
Accepting narrative transition plans without verifiable metrics — a story isn't a plan
Delegating the transformation without having personally demonstrated it — your team copies what you do, not what you say
Letting Level 1 persist without a remediation plan — inaction becomes the norm
Confusing training with transformation — a course doesn't change a workflow, building a system does

11. Performance Expectation

Managers are evaluated on:

The quality of their transition specifications (clarity, verifiability)
The measurable progress of their team
Systems deployed (not planned — deployed)
Reduction of manual effort
Their own demonstration of Level 2+

Not on the number of meetings about AI, nor on the enthusiasm communicated.

Support Provided

Leadership provides:

Access to AI tools (licenses, accounts, infrastructure)
Protected time for learning and experimentation (to be negotiated per team)
Review of transition plans by leadership
Fast escalation for systemic blockers (missing tool, budget, legal question)
The employee guide as a reference framework for your team

Human support mechanisms (to set up within your team):

AI clinics: regular sessions (weekly or biweekly) where the team shares discoveries, blockers, and workflows. Short format (30 min). The goal is peer learning, not formal presentations.
Transition pairing: pair an advanced member with a member who's learning. Skills transfer works better by working together on a real case than through abstract training.
Peer brief review: before submitting, employees review each other's work. An outside perspective catches blind spots.
Your own availability: block explicit time to support your team. If you're not available to answer questions during the transition, it won't happen.

Approved tools (list maintained by leadership):

AI assistants: Claude, ChatGPT (organizational accounts)
Code: GitHub Copilot, Claude Code (engineering)
Automation: Zapier, n8n, Make (department-dependent)
Prohibited for security reasons: any tool that sends client or financial data to an unapproved third-party service
Requesting a new tool: submit to leadership with a business justification — response within 1 week

What leadership will not provide:

A ready-made plan for your team — your expertise is what builds it
A one-size-fits-all generic training — the transformation is specific to each role

Examples: good plan vs bad plan

Bad plan (marketing)

"The marketing team will integrate AI into its content creation and reporting processes. Goal: improve efficiency. Each member will use Claude or ChatGPT daily. Training planned."

Why it's insufficient: no specific workflows, no metrics, no systems to build, no 30/60/90, no acceptance criteria. It's a narrative, not a specification.

Good plan (marketing — role: content manager)

Current state: Writes 4 articles/week manually (~3h each). Ad hoc topic research. No structured template.

Target state (Level 2): Articles generated by AI from a strategic brief (topic, angle, keywords, tone). The human defines the brief and validates the result. Time per article: <1h.

Gap: No structured briefs, no AI workflow, no reusable prompts.

Systems to build: (1) Content brief template. (2) Claude workflow: brief → draft → revision. (3) Shared prompt library.

Metrics: Time per article (from 3h to <1h). Volume (from 4 to 8/week at equal quality). Revision rate (<20% of content modified post-generation).

30/60/90: 30d — brief template + workflow in use on 2 articles/week. 60d — 100% of articles via the workflow. 90d — shared prompt library, documented metrics.

Why it's a good plan: specific, measurable, decomposed, with concrete systems. An independent observer can verify each milestone.

Appendix: Transition Plan Template (per role)

Fill out one template per role on your team. If you can't fill in a field, that's a signal that the corresponding layer isn't completed.

Role: _______________
Incumbent: _______________

─── CURRENT STATE (Layer 2) ───

Main tasks and weekly time per task:
  1. _______________ (~___h/wk)
  2. _______________ (~___h/wk)
  3. _______________ (~___h/wk)
  4. _______________ (~___h/wk)

Repetitive / predictable / template-based tasks:
  - _______________
  - _______________

Tasks requiring human judgment:
  - _______________
  - _______________

Bottlenecks:
  - _______________

─── TARGET STATE — LEVEL 2 (Layer 3) ───

What Level 2 means for this role (3 verifiable sentences):
  1. _______________
  2. _______________
  3. _______________

Redesigned workflows (before → after):
  1. Before: _______________  →  After: _______________
  2. Before: _______________  →  After: _______________

What the employee can decide on their own: _______________
What they must escalate: _______________

─── SYSTEMS TO BUILD (Layer 4) ───

  1. _______________ (tool: ___, estimated effort: ___)
  2. _______________ (tool: ___, estimated effort: ___)
  3. _______________ (tool: ___, estimated effort: ___)

─── METRICS ───

  1. _______________ (current: ___ → target: ___)
  2. _______________ (current: ___ → target: ___)
  3. _______________ (current: ___ → target: ___)

─── 30/60/90 DAYS ───

  30d: _______________
  60d: _______________
  90d: _______________

─── FAILURE CONDITIONS ───

This role has NOT reached Level 2 if:
  - _______________
  - _______________

Summary Rule

Clear thinking precedes transformation.

If you can't specify what Level 2 means for each role, you can't get your team there.

← Back to home · The reference framework · Employee guide · Glossary