Synthesis + graduation demo

Why Week 6 has no new items

The previous five weeks deliberately overshoot what most teams can fully install in 5 calendar weeks. The point isn’t to land all 22 items in 30 days. The point is to install the shape of an AI-native engineering team — the principles, the rituals, the routines, the 10×-everything thinking, the political stances — in a sequence that lets each layer compound on the last.

Week 6 is the week you stop adding and start checking what stuck. Some items will feel solid. Some will feel shaky. Some you’ll have skipped. All of those are OK. The graduation isn’t "everything installed." It’s "honest map of what landed, what didn’t, and what you’re going to keep working on."

1 — The graduation demo

One real outcome you (or your team) shipped during the bootcamp that you couldn’t have shipped six weeks ago. Not because the technology has changed in six weeks — because you have changed.

What qualifies:

• A feature that previously would have required a cross-team handoff and now shipped end-to-end inside your team.
• A bug investigation that previously would have taken days and resolved in hours because of how you briefed the agent against the repo context.
• A process change you proposed and got accepted (Week 5 territory) that previously you would have just complained about privately.
• A piece of work shipped by someone on the team who previously didn’t ship that kind of work — the PM, the designer, the backend engineer doing frontend.
• A support function (Week 3) where you wrote and circulated the 10× upgrade plan, even if the upgrade itself is still in progress.
• The first real production deploy via the deploy-to-prod skill (Week 2), with measurable time-saved over the pre-skill baseline.

What doesn’t qualify:

• A toy demo built specifically for graduation. The whole point is real production work, not exercises.
• A “promise” — “we’ll ship X once Y is in place.” The demo is for what shipped, not for what’s queued.
• Something the team would have shipped anyway, with AI-native practice mostly invisible. The demo is for outcomes where the practice was load-bearing.

2 — The full Friday ritual, run as graduation

The Friday demo + weekly planning ritual has been running since end of Week 1. This week, run it as a graduation exercise — deliberately observed, more time given, with the team explicitly evaluating: is this ritual doing the work it was meant to do?

The graduation Friday demo:

1. Each engineer demos one real outcome (as in §1).
2. The team updates NEXT-STEPS.md for the coming weeks — what continues, what wraps up, what new territory opens.
3. The team explicitly reviews: what about the bootcamp’s practice is staying, what’s drifting, what needs reinforcement.
4. The team makes commitments about post-bootcamp cadence: monthly retros, quarterly re-reviews of the principles, anything that needs an explicit calendar slot to keep the practice from atrophying.

3 — What to measure (and what not to)

The temptation after a transition like this is to measure throughput multiples and quote them. Resist. Throughput multiples are real but variable — year-1 outcomes typically range from 1.5× (heavy org friction) to 3× (organisational autonomy), and the multiple is partly outside your control because of the surrounding org.

What’s worth measuring:

• Production incident rate. Has it gone up, stayed flat, or come down? If it’s up, the 10×-everything chapter (Week 3) didn’t fully install — revisit.
• Cross-discipline PR mix. What fraction of PRs are coming from engineers shipping outside their classical specialism? Trending up is good (Week 4 territory).
• Friday-demo participation rate. Are people consistently showing up with shipped work, or is the ritual feeling like a performance? Trending towards the former is good.
• Self-reported brain-fry frequency. The team that has named brain-fry as a real signal (Week 5 territory in the AgentHerder Course; analogous work applies here for the team that’s pushed too hard) is the team that catches burnout before it causes attrition.
• Process-change proposals shipped. Are you actually getting the political layer to land, or is the push-back staying in the team-internal proposal layer?

What’s mostly not worth measuring:

• PR count alone. PR count goes up when you ship rough first-passes (Week 4). It’s a leading indicator of throughput-mode-change, not of throughput-quality.
• Lines-of-code or lines-changed. As useless as it ever was. Probably more useless now.
• Per-engineer multipliers. Inviting an engineer-by-engineer ranking is a fast way to destroy the trust-each-other-to-ship culture from Week 5. Measure team-level outputs; leave individual evaluation to managers in the normal way.

4 — AgentHerder foreshadowing

The course has taken you (or your team) from Walking to Running stage. The next stage — Flying / Fleet — is a different practice with different mechanics, different emotional work, and a different audience.

The AgentHerder Bootcamp (and its free AgentHerder Course) is the path for engineers who want to push from 1–3 parallel Claude Code sessions to 10+ sustained on real work. Same productisation pattern as this one. The audience: senior engineers (typically individual contributors) who’ve crossed the running threshold and feel the next-stage pull.

Who should push toward flying:

• Engineers running 2–3 sessions today and feeling the ceiling — not the “I can’t learn parallelism” ceiling, the “I want more leverage from my time” ceiling.
• Senior ICs who’ve been told to “figure out AI for the team” and want to take their own practice to the maximum.
• Anyone whose work is inherently parallelizable (multiple independent product surfaces, multi-repo coordination, exploratory R&D) and who’d benefit from a fleet practice.

Who shouldn’t (yet):

• Engineers still consolidating the Running-stage practice. The Running-to-Flying jump is its own transition — don’t stack it on top of an incomplete Walking-to-Running install.
• Engineers whose work is inherently sequential (long deep debugging passes, single-thread research work, work where context-switching is genuinely expensive).
• Engineers who experienced significant brain-fry or burnout in Weeks 4–5 of this course. Stabilise the current practice first.

If you’re going to push toward flying: start with the free AgentHerder Course, work through it as you did this one. If you want the cohort + coaching + Cert exam, the paid AgentHerder Bootcamp is the path.

5 — The post-bootcamp playbook

The practice you’ve installed in six weeks will drift in three months without explicit reinforcement. The hires you make six months from now won’t have gone through the bootcamp; they’ll inherit the practice from the surrounding team and that inheritance is lossy.

What to do about it:

• Quarterly retrospectives on the practice. 90 minutes, once a quarter, explicitly reviewing the principles from each of the six weeks against current state. What’s drifted? What needs reinforcement?
• Onboarding for new hires explicitly references the course (or a curated subset of it). Don’t assume the new hire will absorb the practice through osmosis — assign the course as part of their first 6 weeks.
• A senior engineer (or you) as the practice owner. Someone whose job it is to notice when the practice is drifting and surface it to the team. Usually the person who pushed hardest for the bootcamp in the first place.
• The Friday ritual, forever. The single most-likely-to-be-dropped artefact. The single most load-bearing. Defend it.

Self-check — did the whole course land?

The honest final self-check. If most of these are “yes,” you’ve installed the practice. If most are “no,” the bootcamp didn’t take — and the honest move is to identify which week’s install was shallowest and rerun it.

• Your strategy / spec / decision docs live in the repo as markdown, not in SharePoint / Word / OneDrive / PowerPoint. (Week 1.)
• NEXT-STEPS.md is the single source of truth for your work-stream(s). (Week 1.)
• You record + transcribe meetings via local Whisper and feed the transcripts to Claude as context for follow-up work. (Week 2.)
• You no longer click through routine SaaS / web UIs — Claude drives the browser. (Week 2.)
• Your hand doesn’t touch the git CLI for routine ops, across multiple parallel branches. (Week 2.)
• You have a deploy-to-prod skill, used regularly. (Week 2.)
• You have a 10× upgrade plan for at least one support function, with a conversation started about landing it. (Week 3.)
• You can articulate the “you remain essential” framing in your own words for engineers who feel threatened. (Week 3.)
• The almost-never-say-no reflex has shown up in your week. Non-engineers on your team have shipped PRs. Engineers have shipped outside their specialism. (Week 4.)
• You’ve survived the low-quality phase without reverting. The visible-output dip is on the upswing. (Week 4.)
• You calibrate polish per-surface, not per-team. (Week 5.)
• You’ve formally proposed pushing back on at least one process that assumes hand-crafted code. (Week 5.)
• You’ve spun up at least one mock / replica to unblock from a slower upstream team. (Week 5.)
• The team trusts each other to ship without re-litigating direction in PR review. (Week 5.)
• The Friday demo + weekly planning ritual is reflexive. (Weeks 1–6.)

Eight or more yeses: the practice landed. Reinforce. Five to seven: most of it landed, identify the gaps. Fewer than five: revisit the weeks whose items didn’t take. The course doesn’t time-expire.

Graduation

That’s the course.

Six weeks ago you (or your team) was somewhere on the Walking-stage spectrum — using AI as a useful assistant on some work. Now you’re at Running-stage: AI is the participant, you’re the orchestrator, and your team operates at a cadence that compounds.

That’s a real shift. Don’t let it drift.