Most readers of this document are not founding a new company. They are running, or working inside, an organization that already has a structure — usually some flavor of Agile with two-week sprints, a mix of senior and junior engineers, one or more product managers, possibly scrum masters or delivery leads, and a CI/CD pipeline of varying maturity. The question is not whether Restruct ™ is appealing in principle. The question is how to get from where they are to where the methodology describes, without halting delivery.
This appendix outlines a six-month migration path for a mid-sized engineering organization (roughly 20 to 80 engineers). Larger organizations should expect the same sequence to take twelve to eighteen months and to run in parallel across subsystem domains rather than as a single program. Smaller organizations can compress aggressively. The sequence matters more than the calendar.
Starting conditions
Assume a 40-person engineering organization running six scrum teams of five to seven engineers each, plus a small platform team, two to three product managers, two scrum masters, and a VP of Engineering. The org uses GitHub, runs two-week sprints, holds daily standups, has a backlog refinement meeting and a planning meeting every sprint, and uses Jira for tracking. AI tooling is available but used inconsistently — some engineers heavily, others not at all. No one has a clear policy on AI-assisted code review, generated code ownership, or which AI systems are approved for production work.
This is a recognizable industry baseline. Restruct ™ migration starts here, not from a greenfield assumption.
Phase 0 — Pre-work
(Weeks 0 to 4)
Before any structural change, the organization needs three things in place: a clear subsystem map, a written AI orchestration policy, and identified Principal Architect candidates. None of these require new titles or reporting changes yet.
The subsystem map is a document that names the bounded systems the organization owns — billing, customer identity, the core product workflows, internal admin, the data pipeline, the AI orchestration layer, and so on — along with the interfaces between them. Most organizations discover during this exercise that they have between four and twelve real subsystems, regardless of how many scrum teams currently exist. This map becomes the basis for Architecture Groups.
The AI orchestration policy is a written document — typically two to four pages — that defines which AI systems are approved for production work, what kinds of changes require human-authored specifications before AI execution, who has the authority to run AI-assisted refactors against production code, and what the review trail looks like. The policy is the institutional artifact that makes the Restruct ™ AI boundary real. Without it, the boundary is rhetorical.
Principal Architect candidates are identified from the existing senior engineering ranks. The criteria are not seniority or implementation volume; they are systems reasoning, the ability to write a clear specification, comfort with sequencing dependencies across teams, and demonstrated product judgment. Typically two to four people in a 40-person organization meet this bar. The candidates are told they are being considered for the role and given the methodology to read, but no title change yet.
Phase 1 — Establish the architecture layer and the AI boundary
(Months 1 to 2)
In Phase 1, one subsystem is selected as the pilot. The Principal Architect for that subsystem is named. An Assistant Principal Architect is named, typically a strong senior engineer already working in that subsystem. For this subsystem only, the AI orchestration policy is enforced strictly: only the Principal Architect and Assistant Principal Architect may invoke AI execution against production code, and all AI-generated changes require an approved written specification before execution.
This is the methodology’s most contested commitment and it must be enforced from day one. Half-measures fail. If five people are allowed to run AI orchestration “just for this sprint,” the boundary collapses inside a month. Strict enforcement is uncomfortable at first — engineers who were using AI tooling freely will feel restricted — and the discomfort is the point. The restriction surfaces the difference between AI-as-tool (which everyone keeps for local development, drafting, exploration) and AI-as-execution-against-the-production-system (which is now governed). Engineers retain all their existing AI access for their own machines, sandboxes, branches, and pull requests. What changes is who can authorize AI-generated changes to enter the system of record.
Other engineers in the pilot subsystem keep their existing titles for now. The pilot subsystem keeps shipping. Standups continue. The only structural change is the named architecture layer and the enforced AI boundary. Phase 1 runs for six to eight weeks. The success criterion is not velocity; it is whether the architecture layer is producing reviewable specifications and whether AI execution is being run only through the two authorized roles.
Phase 2 — Introduce specifications discipline
(Months 2 to 4)
By Phase 2 the pilot subsystem expands the architecture layer to include Associate Architects. Two to four engineers from the pilot team are named Associates. Their work shifts from writing implementation tickets to drafting governed specifications: subsystem plans, interface definitions, data contracts, operational breakdowns, sequencing proposals. The Principal Architect reviews and approves these specifications before they hand off to AI execution.
This is the phase where most migrations struggle. Engineers who were strong at implementation are not automatically strong at specification drafting. Some will adapt quickly; some will need coaching; some will not want to make the transition at all. The organization needs to be honest about all three outcomes. Engineers who do not want to become Associate Architects should be offered a path into the Research Fellow track, a parallel implementation-heavy specialist track (which exists outside Restruct ™ ’s core taxonomy and is acceptable for legacy systems or non-AI-governed work), or an exit. Forcing the transition produces worse outcomes than acknowledging the change is real.
In parallel, a second and possibly third subsystem begin Phase 1. The pilot has produced enough specifications and AI-execution review artifacts that the methodology is no longer theoretical inside the organization. Other Principal Architect candidates are named for the new subsystems. The AI orchestration policy applies to them as well.
Phase 3 — Trim ceremony, reframe PM and scrum master roles
(Months 4 to 5)
By Phase 3, subsystems on the Restruct ™ model have several months of specification artifacts and AI-execution review records. The Agile rituals can now be evaluated against actual evidence rather than against fear of removing them. Daily standups can be replaced with continuous async updates in the team channel. Backlog refinement can be replaced with specification review sessions held when there is something to review rather than on a fixed cadence. Sprint planning can be replaced with sequencing decisions made by the Principal Architect against the subsystem plan. Retrospectives can stay; they are one of the genuinely useful Agile artifacts, particularly when they focus on architectural decisions rather than process complaints.
The PM and scrum master roles need explicit reframing rather than elimination. Product managers move closer to the Product / GTM layer described in Chapter 1 — defining operational intent, customer workflows, and constraints — and away from backlog management. Strong PMs find this transition energizing. Scrum masters typically move into one of three places: Research Fellow or Center of Excellence work (governance and methodology refinement is a real job), operational program management for cross-subsystem coordination at larger scale, or out of the organization. The methodology should not pretend the scrum master role survives unchanged.
Phase 4 — Formal role rename and apprenticeship structure
(Months 5 to 6)
Phase 4 is when titles formally change across the organization. By this point, the structure has been operational for several months and the renames reflect what people are already doing. Software Engineer titles convert to Associate Architect, Assistant Principal Architect, or Research Fellow as appropriate. Compensation bands are reviewed; Restruct ™ does not require compensation changes, but title changes without compensation review create suspicion that the rename is cost-cutting in disguise.
Entry-level hiring shifts to the Research Fellow track described in Chapter 11. New graduates are hired into research, benchmarking, QA systems, and specification support roles rather than into implementation positions. The apprenticeship loop becomes explicit: Research Fellow leads to Associate Architect through demonstrated specification quality, Associate leads to Assistant Principal Architect through demonstrated sequencing and review judgment, Assistant Principal leads to Principal through demonstrated subsystem governance.
What can go wrong
The most common failure mode, and the one organizations reach for hardest under delivery pressure, is trying to scale a straining subsystem by widening AI orchestration access instead of splitting the subsystem. Three months in, a Principal Architect is overloaded, a deliverable is slipping, and someone proposes that “just for now” a senior Associate Architect can run AI execution directly to relieve the queue. Every organization that has tried this has had the boundary collapse permanently within a quarter, because the next sprint pressure produces the same proposal and the next one after that, and there is no point at which the conditions for restoring the boundary feel right. The correct response to an overloaded Principal Architect is to decompose the subsystem along its natural seams — SOLID boundaries, bounded contexts, the lines where Conway’s Law was already pulling the system apart — and stand up an additional Architecture Group with its own Principal Architect. Throughput scales through subsystem count, not orchestrator count. The migration team should agree on this principle before Phase 1 begins, because the pressure to violate it will arrive on schedule.
A related failure mode is naming a Principal Architect who is technically strong but cannot write a clean specification or sequence dependencies across teams. The role concentrates authority; a weak Principal Architect concentrates dysfunction. Organizations should be willing to leave the role unfilled in a subsystem for several months rather than fill it with the wrong person. The Assistant Principal Architect can run the subsystem in the meantime.
Another failure mode worth naming is renaming roles in Phase 1 instead of Phase 4. Renaming early signals that the change is cosmetic. The discipline is to change the work first and the titles last, so the titles describe something that already exists.
A final failure mode is treating the migration as a top-down mandate without genuine engagement from the engineers being asked to change roles. Engineers who feel reclassified rather than promoted resist; engineers who feel they are being offered a real upgrade in scope and authority tend to engage. The methodology genuinely is an upgrade for most people, but only if the migration is run that way.
What good looks like at six months
At six months, a successfully migrated 40-person organization runs three to five Architecture Groups against real subsystems, with AI orchestration restricted to Principal and Assistant Principal roles and an auditable specification trail for every governed change. Standups, planning, and refinement have given way to specification review on demand; PMs operate at the Product / GTM layer; scrum masters have moved into operational coordination, research, or out of the organization.
The most reliable leading indicators of a successful migration are not velocity metrics. They are: how long it takes to get a specification approved (target: hours to a few days, not weeks), what fraction of AI-generated production changes have an approved specification on file (target: 100%), how many sprint ceremonies still exist (target: as few as possible, with retrospectives the most defensible survivor), and whether new hires are entering through the research track. Velocity follows from these. Velocity targeted directly tends to compromise the boundary.
An organization six months into a Restruct ™ migration is not a finished organization. It is one that has crossed the threshold where the methodology is operational rather than aspirational. The work of refining specifications, growing Associates into Assistants, building the Center of Excellence, and extending the SDK foundations continues for years afterward. But the structural change — the architecture layer, the AI boundary, the specification discipline, the apprenticeship loop — is in place, and the organization is no longer running on inherited industrial labor assumptions.