Phase 0 · Prepare
Get the pod ready to begin.
Turn interest in AI into a pilot with real work, protected time, and an honest starting point.
The program at a glance
One shared practice. Five phases.
- Phase 0 · Suggested week 0
Prepare
Pod, backlog, access, baselines, tools, and structure.
Current phase - Phase 1 · Suggested week 1
Execute
Agree the design together before generating a change.
Explore phase - Phase 2 · Suggested week 2
Guardrails
Keep changes reviewable and run the quality gates.
Explore phase - Phase 3 · Suggested week 3
Trust
Use AI to understand, explain, and debug the code.
Explore phase - Phase 4 · Suggested week 4
Scale
Transfer the playbook with coaches and rollout waves.
Explore phase
Your destination
What success looks like at the end of this phase
The pilot has leadership sponsorship, a participating pod, roughly two weeks of ready tickets, working access, and a documented performance baseline. People understand the purpose and can raise questions or concerns before committing to the work.
The performance step
Remove the friction before the work begins.
- What improves
- Ready tickets, working access, and protected time let the pod start work without repeatedly waiting for setup or decisions.
- What to measure
- Record ticket start-to-acceptance time, blocked time, review revisions, and escaped defects using the same definitions throughout the program.
- Build on it
- Carry the baseline into Execute so the pair can see where its first accepted changes save time.
Where you are now
Some people already use AI. Others are unsure where it belongs. Access, backlog decisions, and the definition of improvement may still be unresolved.
What you will learn: Set up a pilot that can produce useful learning and accepted delivery work.
The team you start with
Two pods. A shared support system.
Bring engineering, product, quality, and program coordination into each pilot pod.
Pilot pod 1
- Engineers
- 2
- Product Manager
- 0.5Half-time allocation
- QA Engineer
- 0.5Half-time allocation
- Program Manager
- 0.5Half-time allocation
Pilot pod 2
- Engineers
- 2
- Product Manager
- 0.5Half-time allocation
- QA Engineer
- 0.5Half-time allocation
- Program Manager
- 0.5Half-time allocation
Shared support across both pods
Read: the team behind AI-assisted engineering →
Make room to practice
The proposed rhythm is preparation followed by four working weeks, with a daily 60-minute deep standup, protected delivery time, and two advisory reviews each week. Agree the actual commitment with your sponsor and coach. Readiness determines progression, and a phase may need more time.
Bring a repository, representative tickets, approved tools, and the delivery and quality evidence you already have. Prepare will help you identify the gaps. Existing review, testing, security, and release safeguards apply from the first change.
What to do in this phase
Step 01
Secure sponsorship and select the pod
Ask a named leader to sponsor the pilot and protect its working time. Select curious, self-directed engineers who can work through ambiguity and influence peers. Establish the product, QA, and program-management partners. The cohort starts with two pods; agree shared roles and support before kickoff.
Step 02
Load a ready backlog
Product should already be creating tickets: teaching product to write its backlog is outside this program. Assign multiple valuable, independent tickets, with approximately two weeks of ready work as a starting point. Minimize external dependencies and agree acceptance criteria before the pod begins.
Step 03
Record the starting performance
Capture the available baseline for delivery velocity, cycle time, quality, build health, incidents, and performance. Keep the same definitions for the later comparison. Name missing sources and unusual work rather than inventing a baseline or counting every ticket as equal.
Step 04
Remove operating friction
Map approvals, CI/CD, security review, repository and tool access, and current AI experience. Have both engineers run the repository and relevant checks. Give each blocking dependency an owner before starting implementation.
Step 05
Agree the commitment and working rhythm
Explain why the organization is running the program and invite questions. People can disagree with an approach and still agree to test it; do not require enthusiasm. Define a respectful route to seek support or leave the cohort. Protect daily 60-minute deep standups and twice-weekly advisory reviews, with delivery time outside those sessions.
Your working session
Try this with your team
Use your starting note to complete the pilot charter in your team’s working document. Ask the product partner to explain the first ticket, then have both engineers run the setup and checks. Give each unresolved access or behavior question an owner.
Make this: A pilot charter, ready backlog, verified setup checklist, and baseline worksheet.
Plan the kickoff with your coach →
Use a practice guide when you reach this step:
A worked example
A pair chooses workspace-invitation work because behavior decisions often emerge late in review. Their question is whether an agreed specification can reduce avoidable revisions. They record available review revisions and acceptance timestamps, noting that these do not capture every hour of effort. The first setup check exposes missing tool access; the program lead resolves it before implementation.
How success feels
- I understand why we are doing this and can ask questions about it.
- We have enough ready work and the people we need to begin.
- I know what I am committing to and how to ask for support.
Use the signals below to check your progress with the team.
Signals of success
- A named leader sponsors the pilot and protects the pod’s time.
- Product is already supplying tickets with clear acceptance conditions.
- Multiple tickets are assigned, with roughly two weeks of ready work and known dependencies.
- Both engineers have working access and can run the required checks.
- The starting performance measures, questions, and participation expectations are documented.
If you are stuck
- Waiting on access. Assign an owner and verify resolution before implementation starts.
- The ticket is vague. Write a smaller, testable specification with product.
- Historical data is missing. Begin a consistent baseline now and narrow comparison claims.
Coach checkpoint
Before you move on
Review sponsorship, the ready backlog, access, baseline, and participation agreement with the coach. The phase is complete when the pod can start its first real ticket without a missing organizational decision blocking it. Resolve remaining preparation blockers before moving into Execute.
Your next action: Bring the charter, assigned tickets, baseline, and open program questions to the kickoff review.
Reading independently? Use these questions for self-review. Discuss participation and artifact feedback with a coach through a cohort enquiry.