Developer Productivity & Operational Enablement

At 7% — roughly four items — this is the smallest domain on CCAR-P. The honest advice is to study it last and study it once. Nothing here rewards depth; do not trade time away from RAG, evaluation or governance to over-prepare it.

What it tests is enabling a team, not personal fluency. You are framed as the architect standardizing Claude tooling across many developers: where configuration lives, what belongs in version control versus on one machine, how tool permissions are set once and inherited, how a new joiner gets a working setup on day one, and how you help someone diagnose an agent that took the wrong action.

The trap is answering as an individual power user — clever prompts, personal aliases, local tweaks. Credit goes to the choice that scales to everyone and survives the author leaving the team.

The unlocking idea: treat agent configuration as code — project-level, reviewed, versioned, reproducible. Then measure impact against a baseline captured before rollout, and report it with the skepticism you would apply to any other engineering claim.

• Configuration is code. Anything the whole team depends on lives in the repo, under review and version control — not in a wiki page, an onboarding doc, or a screenshot in chat.
• Split by scope. Shared project config is committed; personal preferences and machine-specific paths stay in the developer's local, gitignored settings; org-wide non-negotiables arrive as enterprise-managed settings a developer cannot override.
• Put durable project knowledge in the project memory file (CLAUDE.md at the repo root): build and test commands, directory conventions, house style, and the things Claude keeps getting wrong. It is documentation that both humans and agents read.
• Keep memory files short and imperative. Every turn pays for them in context. A bloated instruction file dilutes the few rules that actually matter.
• Share tool definitions, never tool credentials. Define MCP servers in committed project config; inject secrets per developer from the environment or a secret manager.
• Codify repeated workflows as artifacts — slash commands, subagents, hooks — so the team's best prompt is a reviewed file, not tribal knowledge.
• Set permissions once, at the team level. Allow-list the safe, high-frequency tools; deny destructive ones outright; require explicit approval at the real boundaries — production writes, network egress, secret access.
• Roll out in cohorts. Pilot with a willing team, fix what breaks in the paved path, then widen. Org-wide day-one rollout produces org-wide day-one abandonment.
• Baseline before you enable. With no pre-rollout measurement, no honest claim is available to you afterward.
• Onboarding bar: clone and go. A new developer clones the repo and has a correctly configured agent with no manual setup steps and no one's private notes.
• Attribute spend from the start — per team, per repo, per workflow. Usage nobody owns is the first line finance cuts.
• Enablement is continuous: office hours, a channel where patterns that worked get shared, and periodic review of the shared config as the codebase moves under it.

• The most common wrong answer is a solution that works for one expert. If it does not survive that person leaving, it is not an architecture — it is a habit.
• Anti-pattern · config drift. Every developer curates their own instructions and tool setup, so behavior is unreproducible and nobody can debug anyone else's session.
• Anti-pattern · the god-sized memory file. Hundreds of lines of aspirational rules; the agent honors the first few and the rest is expensive noise on every turn.
• Anti-pattern · secrets in shared config. Committed server definitions are fine; a committed token is an incident with the whole team's name on it.
• Anti-pattern · blanket auto-approval to stop the permission prompts. Convenience bought with the blast radius of every developer at once.
• Anti-pattern · rollout as announcement. Access granted, no paved path, no worked examples, no one to ask. Low adoption is usually an enablement failure, not a tooling failure.
• Vanity metrics to refuse: lines of code generated, suggestion acceptance rate, session counts, and self-reported time saved with no comparison group.
• Metrics that survive scrutiny: cycle time on comparable tasks, review rework, defect escape rate, time-to-first-commit for new joiners, and cost per completed task — read against a pre-rollout baseline and, where possible, a control cohort.
• Watch for displaced cost. Faster authoring that raises review load or defect rate is a transfer, not a gain; measure downstream of the keyboard.
• Debugging starts with the transcript, not the prompt. Which tools were called, with what arguments, and what came back. Most "the model got it wrong" reports are a bad tool result, a missing permission, or a stale instruction.
• Isolate the layer before changing anything: instructions, context and retrieval, tool schema, permissions, or model reasoning. Reproduce with a fixed input in a clean context to separate a real regression from context pollution.
• "It worked yesterday" usually means precedence, not drift in the model: check for contradictions between user-level, project-level and subagent configuration.

ADOPT — the sequence for putting Claude tooling into a team's hands.

• A — Anchor. Capture the baseline and name the outcome you intend to move, before a single developer is enabled. No baseline, no honest claim later.
• D — Declare. Shared configuration declared as code in the repo — project memory, settings, MCP servers, commands, subagents — reviewed and versioned; personal and machine-specific settings stay local.
• O — Onboard. Clone-and-go setup, worked examples of the workflows that matter, and a named place to ask. One willing cohort first, then widen in waves.
• P — Protect. Tool allow-lists, approval at real boundaries, per-developer secrets, and cost attribution set once at team level rather than per laptop.
• T — Track. Report outcome metrics against the baseline, state what you cannot attribute, and triage misbehavior from the transcript rather than the prompt.

Use ADOPT whenever a question asks how to take Claude from one developer's laptop to a team's default workflow — and use it to test whether your answer survives the person who wrote it leaving.