AI engineering · Module 21 of 21 · Level 6: Lead the team
Leading your team's AI adoption
Getting good with AI tools yourself is half the job. The other half is helping a team get good with them together: shared rules instead of private tricks, tools approved the way dependencies are, and evidence that the work got better, not just busier. This module turns the 26-week roadmap into a six-month rollout you can run alongside it.
1. The idea
A head chef bringing a new combi oven into a busy kitchen doesn't hand everyone the manual on a Friday night. They cook on it themselves for a few weeks first, then teach one station at a time. The settings that work get written on a card taped to the oven, so the night shift gets the same results. Nobody plugs in a new gadget without the chef checking it first. And the chef judges the oven by the plates sent back, not by how often it's switched on.
- Stay one phase ahead. Learn a phase of the roadmap yourself, then run it with the team the following month. You teach from experience, not from the launch video.
- Put the setup in the repo, not in people's heads. Team rules, AGENTS.md, permission baselines, skills and hooks are committed files (Modules 09–12), so every teammate and every tool starts from the same place.
- Approve tools like dependencies. MCP servers, plugins and skills run code with your permissions (Module 18). Each one gets a review, a pinned version, a named owner and a place on an approved list.
- Measure outcomes, not usage. Track pull-request cycle time, defect rate and escaped bugs in AI-assisted work. Usage only tells you people opened the tool.
2. How it works
3. Try it yourself
Is the rollout working?
Enter a team's numbers from the quarter before the rollout and the latest quarter, or pick an example team. The verdict reads outcomes first and usage last.
Your rollout checklist
Tick what your team already has. The bar shows how far along you are; the first unticked item is your next step. Saved in this browser only.
4. Why it matters at work
The six-month rollout
| When | What you roll out to the team |
|---|---|
| Month 2 | An "LLM basics" explainer and team AI coding rules. Everyone picks a primary agent and tries a second one. |
| Month 3 | A shared AGENTS.md in every repo; committed agent settings with a safe permission baseline. AI-assisted pull requests say which tool was used and are reviewed by a person. |
| Month 4 | An approved list of MCP servers and plugins; a team skills library; AI pull-request review in CI. |
| Month 5 | The first AI feature in the product, behind a provider interface; an internal MCP server. |
| Month 6 | Eval sets required for every AI feature; a security checklist in the pull-request template; a quarterly tool scorecard. |
Team rituals that keep it going
- Friday AI share-out (15 minutes). One person demos something they learned. Rotate weekly, so everyone teaches.
- Tool scorecard. A shared table rating tools on the same tasks (feature build, refactor, tests, debugging), refreshed quarterly so tool choices stay evidence-based (Module 20).
- Pairing. Pair a stronger AI user with a newer one for one task per sprint.
- Reviews for skills and plugins. New skills, MCP servers and plugins arrive through a pull request with a named reviewer, like any dependency.
- Metrics. Pull-request cycle time, defect rate, escaped bugs in AI-written code and time saved per tool, reviewed monthly.
Governance without a bottleneck
- One approved list for models, tools, MCP servers, plugins and skills, each with an owner, a pinned version and a review date. Re-review it quarterly and remove what nobody uses: every enabled plugin adds context and attack surface.
- Organisation controls where your plan supports them: managed settings that set the permission baseline and block unapproved servers or plugins, data-retention terms you have actually read, and usage or audit logs reviewed monthly.
- A team plugin that bundles your skills, commands and subagents (Module 12), so one install gives a new hire the whole toolkit.
Keep the gate fastA review that takes three weeks teaches people to install things privately. Aim for the 5-minute review in section 2, done within a day, with a clear owner. Slow governance creates shadow tools; fast governance keeps them on the list.
5. In your five tools
What the team commits to the repository, so every teammate gets the same setup. Taken from Modules 09, 12 and 18; checked October 2026.
| Tool | Shared instructions | Shared settings and permissions | Shared subagents, hooks and plugins |
|---|---|---|---|
| Claude Code | CLAUDE.md (start it with @AGENTS.md); .claude/rules/ | .claude/settings.json: allow, ask, deny. Organisations can push managed settings users can't override | .claude/agents/*.md; hooks in .claude/settings.json; /plugin marketplaces |
| Antigravity CLI | AGENTS.md or GEMINI.md; .agents/rules/*.md | toolPermission and enableTerminalSandbox in settings | /agents, /hooks, /plugin |
| GitHub Copilot | .github/copilot-instructions.md, AGENTS.md; .github/instructions/*.instructions.md | Cloud agent behind a firewall allowlist; the person who asked can't approve its PR | .github/agents/*.agent.md; Agent Plugins |
| Cursor | AGENTS.md; .cursor/rules/*.mdc | sandbox.json; rules in permissions.json | .cursor/agents/*.md; .cursor/hooks.json; marketplace plugins |
| Codex CLI | AGENTS.md (nested files merge) | sandbox_mode and approval_policy in config.toml | .codex/agents/; .codex/hooks.json; plugins |
Write the shared rules once in AGENTS.md; every one of the five tools reads it. Git's own pre-commit hooks also apply to every tool, because they run whoever (or whatever) commits.
6. Remember it
Memory hook: "One phase ahead, setup in the repo, outcomes over usage"Learn it before you teach it, commit what the team shares, and judge the rollout by the work it produces.
How this hook works: what “One phase ahead, setup in the repo, outcomes over usage” means
What the slogan means, phrase by phrase
- “One phase ahead”
- You run each phase on your own work a month before the team does, so you teach what actually happened, including what went wrong.
- “setup in the repo”
- Rules, AGENTS.md, permissions, skills, hooks and the approved list are committed files with reviewers, not tips in a chat thread.
- “outcomes over usage”
- Cycle time, defects and escaped bugs say whether the work improved. Seat counts and prompt counts don't.
Why this picture fits: the chef cooks on the oven first, tapes the settings to it, and counts the plates sent back. Each phrase is one of those three habits.
The story → the concept
| The kitchen | Your team |
|---|---|
| The chef cooks on the oven for weeks first | You run each phase a month ahead |
| Teaching one station at a time | One phase per month, with a share-out each week |
| The card taped to the oven | AGENTS.md, settings and skills in the repo |
| The chef checks every new gadget | The approved list: review, pin, owner |
| Plates sent back | Escaped bugs and defect rate |
| How often the oven is on | Usage: the number not to optimise |
Watch it on an example
- Month 3: two engineers have great private prompts; everyone else struggles. You turn their prompts into the team's AGENTS.md and one skill, reviewed in a pull request.
- Month 4: someone wants a database MCP server. It goes through the 5-minute review, read-only, pinned, owned by the data lead.
- Month 6: AI-assisted pull requests merge faster, but escaped bugs rose. You add an eval set and a review checklist before expanding further.
The trap it saves you from
A rollout that looks great on a usage dashboard while quality quietly drops and every engineer runs a different, unreviewed setup.
It still works when…
The tools change. The habits (learn first, commit the shared setup, approve like dependencies, measure outcomes) apply to whatever the team uses next year.
7. Common mistakes
Mandating a tool before anyone has used itTeams copy what they see working. Run the phase yourself first, then show your own before-and-after.
Measuring usage"80% of engineers used the agent this week" says nothing about quality. Track cycle time, defects and escaped bugs, and compare with the quarter before.
Private setupsRules in personal config files can't be reviewed or shared. Commit the team's rules; keep personal preferences personal.
Installing plugins and MCP servers without reviewThey run code with the engineer's permissions. Review, pin a version, install at the narrowest scope, and add it to the approved list.
A gate so slow people route around itIf approval takes weeks, tools get installed privately. Keep reviews small, fast and owned.
Skipping human review because the AI reviewed itAI review in CI is a first pass. A person still approves every merge and every release.
8. Hands-on lab (alongside roadmap months 2–6)
- Baseline (20 minutes). From your Git host, record last quarter's median pull-request cycle time, defects found in review and bugs that reached production. You'll compare against these.
- Write the team rules (30 minutes). One page: which tools are allowed, which data must never go into a prompt, how AI-assisted pull requests are labelled and reviewed. Put it in the repo and ask for review.
- Ship the shared setup (1 hour). AGENTS.md, a committed permission baseline that denies secrets and destructive commands, and one skill turned from someone's private prompt.
- Start the approved list (30 minutes). A table with name, version, owner, scope and review date for every MCP server, plugin and skill in use today. Remove one nobody uses.
- Run the first share-out (15 minutes). Demo one thing from your own last month, including what went wrong.
- Review in a month. Fill in the "Is the rollout working?" widget above with your baseline and new numbers. Decide: expand, hold, or fix quality first.
9. Self-check quiz
What does "stay one phase ahead" mean for a team lead?
You teach from your own experience on real work, including the failures.
Where should the team's AI coding rules live?
Committed files are reviewed, versioned and read by every tool and every teammate.
How should a team adopt a new MCP server or plugin?
They run code with your permissions; review them as you would any code you depend on.
Usage is up and pull requests merge faster. Which number decides whether to expand?
Faster merges are only good if quality holds; escaped bugs show whether it did.
What usually happens when tool approval takes weeks?
Slow governance creates shadow tools. Keep the review small, fast and owned.
10. Go deeper
| Resource | Time | Why |
|---|---|---|
| Case study C01: a repository set up for agents | 20 min | What "setup in the repo" looks like in a real project, layer by layer. |
| The 26-week roadmap | 5 min | The phases you stay one ahead of, and where the team rollout fits. |
| Module 12 and Module 18 | Review | Team plugins, hooks, permission baselines and the plugin review. |
| Module 20: Choosing tools | Review | The scorecard your team refreshes each quarter. |
| DORA research | 30 min | Long-running research on software delivery metrics, including how AI adoption affects them. |