Restruct ™ does not arrive in a vacuum. Skelton and Pais’ Team Topologies (2019) made the modern case that team structure is itself an architectural decision, building on Conway’s Law and treating cognitive load as a first-class constraint. The DevOps and platform-engineering literature — Accelerate, the State of DevOps reports, the platform-as-product movement — has spent the last decade arguing that flow, not ceremony, is what scales.
Restruct ™ accepts those foundations and extends them into the AI-native era. Where Team Topologies asks how teams should interact , Restruct ™ asks what is inside the team when AI absorbs most of the implementation labor . The two frameworks are largely complementary: Team Topologies describes the connective tissue between groups; Restruct ™ describes the internal anatomy of those groups once AI execution becomes the default implementation layer.
Restruct ™ organizes software teams around governed architecture rather than generalized implementation labor. It separates organizations into explicit architectural layers with defined operational responsibilities.
Business Executive owns organizational goals, capital allocation, market positioning, and business outcomes — what the organization is trying to achieve.
Product / GTM translates business goals into operational direction: customer workflows, feature priorities, commercialization strategy, and user-facing outcomes. In Restruct ™ , "product" is not limited to commercial software — it also covers internal operational systems, automation, workflow modernization, AI enablement, and process optimization. Product responsibility sits closer to operational architecture than backlog management; it defines intent, constraints, workflows, and desired outcomes before execution begins.
Principal Architect governs the system itself for the purpose of risk mitigation — architectural authority, subsystem governance, sequencing, technical standards, AI oversight, implementation orchestration, QA governance, and inter-system coordination. In AI-native organizations, Principal Architects should also possess strong product and GTM awareness. One of the highest-leverage emerging profiles is an experienced architect with MBA-level business reasoning. At small scale, a sole Principal Architect may handle product translation, architecture, specification drafting, sequencing, AI orchestration, execution review, and QA governance directly.
Assistant Principal Architects (one or more, depending on group size and subsystem complexity) are the primary execution partners: subsystem coordination, specification review, AI execution oversight, architectural continuity, and QA review.
Only the Principal Architect and Assistant Principal Architect interact directly with governed AI execution agents. This boundary is intentional. AI operates underneath the governance structure, not beside it. Restricting orchestration authority prevents fragmented architectural intent, uncontrolled implementation drift, and degraded context continuity.
Associate Architects scale execution horizontally. They do not interact with AI agents and are not generalized implementation labor. They draft governed specifications, subsystem plans, operational breakdowns, interface definitions, and execution contracts under Principal Architect direction — functionally similar to legal associates drafting contractual frameworks for partner review. Their output is governed architectural intent, not raw implementation. Associate Architects are often early-career technical professionals who develop expertise through systems reasoning and specification drafting under close mentorship, rather than years of repetitive implementation labor.
Research Fellows support the organization through sandbox prototyping, tooling evaluation, AI workflow experimentation, benchmarking, QA systems, documentation, and emerging-trend analysis. At larger scale they consolidate into Research Organizations or Centers of Excellence operating horizontally across the company.
Architecture Group composition: the five-person rule
While a small project can perform well with only a single Principal, a fully stacked Architecture Group should hold up to five people: one Principal Architect, one Assistant Principal Architect, and three Associate Architects. The five-person rule is a guideline rather than a constraint, but it earns its place because it captures the natural cognitive-load limit of a single bounded subsystem under governed AI execution. Three Associates is the most a single Principal can review specifications for without becoming the bottleneck the methodology is supposed to remove.
Three modes of operation cover most real situations:
Mode A — one five-person group. The recommended baseline. When the group reaches five and demand keeps growing, the signal is to decompose the subsystem and stand up a second Architecture Group rather than continue adding people to the first.
Mode B — grown group. An Architecture Group can grow past the ideal headcount when the subsystem genuinely cannot be cleanly decomposed yet. A common shape is one Principal, two Assistant Principals, and five Associates. This is an explicit acknowledgment that decomposition is the right answer but the seams are not yet visible, not an invitation to grow indefinitely.
Mode C — wildcard staff engineers. Where neither mode A nor mode B fits cleanly, the organization can fold in wildcard staff engineers to fill specific gaps — deep technical specialists who do not sit on the Architect ladder but hold high-leverage work the group needs. Staff engineers appear in two other contexts in the methodology (production-PR governance in Chapter 10, elastic capacity in Chapter 12); the same role serves all three.
Notably, this structure contains no traditional Software Engineer titles. This is intentional. In AI-native environments, the AI execution layer behaves as the generalized implementation engine itself.
The AI execution layer is also swappable. An organization not yet ready for agentic implementation can substitute human labor in that slot — handwritten code, optionally assisted by inline tools like Copilot, but not by agentic systems that operate autonomously. What the methodology does not support is hybridizing the two within a single subsystem; a given execution layer is either agentic or it is not. This makes the layer an escape hatch for organizations that have judged agentic coding inappropriate for their needs, or a transition path for legacy organizations adopting Restruct ™ incrementally.
Readers familiar with Team Topologies will recognize the underlying shape. A Restruct ™ Architecture Group is a stream-aligned team; Research Fellows and the Center of Excellence are an enabling team; the governed AI execution layer plays the platform-team role, a product consumed rather than a ticket queue. Complicated-subsystem teams still apply where they always did — a specialist group for, say, a real-time pricing engine or an ML training pipeline can carve out without altering the broader model.
What Restruct ™ adds on top is an answer to a question Team Topologies deliberately leaves open: who sits inside a stream-aligned team when AI absorbs most of the implementation labor? The Principal Architect, Assistant Principal Architect, and Associate Architects are that answer. The Team Topologies taxonomy describes the connective tissue between groups; Restruct ™ describes the internal anatomy of a group in an AI-native environment.