CCA Professional M5: Team Enablement and Readiness

The Champion-Per-Department Rollout Pattern

Why Direct Batch Rollout Fails

Enabling 50 team members simultaneously across an organisation typically produces:

• Most usage stalls at basic chat (users don't know what Claude can do in their specific context)
• Each person solves the same setup friction independently
• No shared configuration emerges — everyone drifts toward personal setups
• The organisation ends up with 50 personal configurations that can't be maintained or improved collectively

The Champion Pattern

1. Enable one champion per team first — give them full access, let them discover and solve the friction for their team's actual workflow
2. Capture the champion's solved configuration — CLAUDE.md, MCP connections, permission posture, and prompting patterns — into version-controlled shared configuration
3. Seed adoption in batches from that baseline — subsequent team members start from the proven configuration, not from scratch
4. Champion absorbs the remaining friction as the rest of the team onboards

This produces adoption at the pace of friction removal, not at the pace of individual discovery.

Shared Configuration vs Personal Configuration

The architectural principle: teams should start from a shared baseline, not from personal defaults.

Shared configuration components:

A team where every member has a different Claude configuration is a team with no institutional knowledge about how Claude is being used. When a problem occurs ("why did Claude make this architectural decision?"), there is no shared baseline to diff against.

The Verification Checklist for AI-Generated Code

AI-generated code must pass four dimensions before production:

The Human-Understanding Dimension

Human understanding is the dimension that can never be automated away, and it's the one the exam specifically tests.

Why it matters: code that passes all automated checks but that no one on the team understands is the slow-burn failure mode. It goes live, passes CI, and becomes unmaintainable the moment it needs to change — because no one can safely reason about its behavior.

Diligence: this dimension is what the study guide calls "diligence" — taking responsibility for verifying and vouching for AI-generated output. An engineer who ships code they don't understand is not being efficient; they are deferring risk.

The session anchoring trap: the same Claude session that wrote the code cannot be the final reviewer of that code. The model is anchored to its own output and will rationalize rather than critique. Code review must use a fresh session or a human reviewer.

Runbook Structure

A runbook captures the symptom-to-cause-to-action path for recurring operational issues:

Symptom: [observable signal in production]
  ↓
Cause: [what this signal indicates about the system state]
  ↓
Action: [specific steps to take, in order]
  ↓
Escalation: [when to escalate, and to whom]

Why the cause layer matters: without it, engineers facing a symptom take actions based on pattern-matching ("last time this error appeared, I restarted the service"). If the underlying cause differs this time, the action is wrong. The cause layer forces the engineer to confirm the diagnosis before acting.

Escalation path: a named definition of who handles what, and when an issue leaves the team. The escalation path is the organisational counterpart to the runbook's technical knowledge. Without it, escalation is improvised — which means during an incident is when the team discovers who to call.

Operational Principles for AI-Augmented Teams

Diagnose before rewrite: when a Claude workflow produces unexpected results, inspect the traces (inputs, retrieved content, tool calls, outputs) before touching the system prompt. The most common cause of unexpected output is unexpected input — not a bad system prompt.

Independent review principle: the same session that wrote the code cannot be the final reviewer of that code. Apply this also to documentation, architectural decisions, and content generated at scale — the producing session is anchored to its output.

Shared runbooks over Slack expertise: operational knowledge that exists only in one engineer's head (or in a Slack thread) is not institutional knowledge. Any issue resolved more than once should be in the runbook.

Module 5 Trap Patterns

Trap 11 — Architectural complexity justified by the wrong reason: in a team enablement context, this appears as distributing org-provisioned skills "because we can afford the platform tier" rather than because the capability belongs to everyone. Reach is a deployment characteristic, not a justification for widest distribution.

Session anchoring in code review: "I asked Claude to review the code it just wrote" is never a valid review step. It looks like a review step and produces review-shaped output, but the model is anchored to its output and will rationalize rather than critique.

Key Rules to Memorise

• Skills distribution: org-provisioned (reach, no rollback) / plugin (versioned, rollback) / project Skill (repo-scoped) / API Skill (version-pinned)
• Spend posture: model defaults + allowlists + effort guidance + spend/rate/per-user caps — set before the first bill
• Champion rollout: enable one champion per team first, capture their config, seed the rest from that baseline
• Verification checklist: correctness / security / maintainability / human understanding
• Human understanding is the dimension that can never be automated away
• Runbook: symptom → cause → action → escalation (cause layer prevents wrong-action pattern-matching)
• Independent review: same session that wrote cannot be final reviewer
• Diagnose from traces before editing system prompts