FAQ

Frequently asked questions

Practical answers about running the program, checking readiness, and planning the next wave.

How long does the program take?

Preparation followed by four working weeks is the suggested rhythm. Protect a daily 60-minute deep standup, delivery time, and two advisory reviews each week. Agree the commitment with the sponsor and coach; use each phase’s evidence to decide when to progress. Prepare the pod →

Do I need to join a cohort to use the guides?

The published curriculum and guides are available for independent use. A coached cohort adds discussion, artifact feedback, and checkpoint reviews. Independent readers can use the questions for team self-review and bring unresolved decisions to their own responsible leaders.

Can we combine phases?

Activities can overlap: testing and security controls apply from the first change, and context improves throughout. Keep the phase outcomes visible and review the evidence for each one. Combining sessions should still leave the team able to demonstrate the capabilities. Review the phases →

What if quality drops as we move faster?

Keep the rollout bounded. Identify the failing checks, review burden, rework, or defects; assign a repair and repeat a smaller change. Review delivery and quality together before expanding. Measure what improved →

Should a ticket be completed in one prompt?

A ticket may need several focused prompts and iterations. Agree on intent first, then generate and verify useful increments. Return to the specification when assumptions keep changing. Run a deep standup →

Who belongs in each pilot pod?

The proposed starting allocation is two engineers, 0.5 Product Manager, 0.5 QA, and 0.5 Program Manager per pod, with a coach and sponsor supporting both pods. The fractional allocations describe working time. Agree who fills each role and how that time is protected. See the starting team →

Which tools do we need?

Use approved AI tools, a repository the pair can run, representative tickets, and working review, test, security, and release checks. Resolve access before implementation. Choose the tools within your organization’s requirements and keep the acceptance evidence visible. Set the guardrails →

How do we know we are ready to scale?

A receiving pod should be able to apply the playbook, explain its choices, and produce reviewed work. Bring its feedback, the repaired playbook, and delivery-and-quality evidence to the sponsor and coach. Agree the next bounded wave and its owner. Review the Scale checkpoint →

Does marking a chapter reviewed mean we are ready?

The reading indicator records chapters reviewed in this browser. Readiness comes from the work: specifications, checks, accepted changes, explanations, and transfer evidence. Use the phase checkpoint to review those outputs with the team.

Is the calculator showing results we have achieved?

The calculator models the assumptions entered. The 50-engineer example applies 30% improvement only to the cumulative 5, 30, and 50 engineers trained by Months 1, 2, and 3. Compare your own measured delivery and quality separately, then revise the planning inputs. Build a before-and-after comparison →

Explore the practice guides →