Chapter 7: Structural Archetypes
Chapter 6 redefined the unit of execution. This chapter addresses the next question: what structural shapes do those units take when arranged into a hybrid organization?
Not every team in a hybrid organization is the same kind of team. They have different relationships to the execution layer, different ownership profiles, different scaling dynamics, and different governance requirements. Treating them as interchangeable produces an organizational structure that is formally clean but functionally incoherent.
Four structural archetypes appear consistently in well-designed hybrid organizations. Three are permanent — standing organizational units with ongoing mandates and accountability that persists as long as the domain they own exists. One is a temporary instrument — assembled to solve a specific execution problem and dissolved when that problem is resolved. The distinction between the two tiers is structural, not semantic. Managing a temporary instrument like a permanent team produces organizational sediment. Treating a permanent team as disposable produces accountability gaps.
The Core Idea
The three permanent archetypes:
Product teams own outcomes in a defined domain of the product or service. They are responsible for what the product does and how it performs for the people who use it. Their execution surface typically combines human-led work — product decisions, design, complex engineering — with an automated layer that handles volume, reliability, and consistency. The team's primary accountability is to the product outcome, not to the technology that produces it.
Platform teams own the internal execution infrastructure that other teams depend on. They do not build products for external users — they build the systems, tools, and services that product teams and other internal teams use to execute. Their execution surface is heavily system-led and automated — the platform itself is the primary executor, and the team's primary work is designing, governing, and improving it. They are accountable for the reliability, capability, and fitness for purpose of the infrastructure they provide.
Automation capability groups own the organization's ability to automate well — not the automations themselves. They own the patterns, standards, tooling, and governance frameworks that enable teams across the organization to build and operate their own automated execution layers. A capability group that builds automation on behalf of other teams has misunderstood its mandate. One that raises the organization's capacity to govern and improve its own automated execution is fulfilling it. Their primary accountability is to the organization's overall automation maturity and governance quality.
The temporary instrument:
Execution pods are small, focused units assembled around a specific execution problem — typically one that is high-volume, time-bound, or requires rapid iteration between human judgment and automated execution. They are not permanent structures. They form when a problem requires a tight integration of human and system execution, operate until the problem is solved or the execution pattern is stable enough to absorb into a product or platform team, and then dissolve. Their execution surface is deliberately experimental — the pod exists partly to determine what the right execution mode for a workflow should be before that decision is locked into a more permanent structure.
A pod is formed with an explicit dissolution condition — a defined answer to the question of how the organization will know when the pod's work is done. That condition is built into the pod's charter at formation. Without it, pods default to permanence, becoming organizational sediment that persists past the problem that justified their existence.
What This Looks Like
A mid-sized technology company operating an e-commerce platform runs all four archetypes simultaneously, each with a distinct execution surface and ownership profile.
The checkout product team owns the checkout experience end to end. Its execution surface includes the engineers building and iterating on the checkout flow, an A/B testing system running continuous experiments, a fraud detection layer operating in system-led mode that routes borderline transactions to a human review queue, and a performance monitoring system tracking conversion and latency in real time. The team is accountable for checkout conversion, reliability, and customer experience. It does not own the underlying infrastructure — that belongs to the platform.
The infrastructure platform team owns the cloud infrastructure, deployment systems, and observability tooling that every product team depends on. Its execution surface is primarily automated — infrastructure provisioning runs on demand without human intervention, deployments execute through a fully automated pipeline, and the monitoring stack operates continuously. The team of seven engineers governs a system layer that serves forty product engineers. Their accountability is infrastructure reliability, deployment velocity, and the fitness of the platform for the product teams that depend on it.
An execution pod was assembled around a bounded problem: the returns processing workflow requires twenty minutes of manual analyst time per transaction, and volume has made that a bottleneck. Its mandate is specific — design and validate an automated execution model for returns processing. Its dissolution condition is explicit: when the automated model is validated, handed to the relevant product team, and the capability group has reviewed the governance model. At that point, the pod dissolves.
The automation capability group of three senior engineers does not own any specific automation. They own the automation standards, the governance framework for AI agent deployment, the tooling that makes it easy for product teams to build and monitor their own automated workflows, and the review process that ensures automation entering the organization's execution surface meets governance requirements. When the returns processing pod completes its work, the capability group reviews the automation design before it is handed to the product team.
How to Evaluate Each Archetype
The four archetypes are not evaluated the same way — because they own different things and produce different kinds of value. Applying a single evaluation model across all team types is one of the most common structural errors in hybrid organizations. It typically manifests as evaluating every team on delivery velocity — a metric that is meaningful for product teams and largely irrelevant for platform teams and capability groups.
Evaluating product teams.
Product teams are evaluated on outcome metrics, not delivery metrics. The accountability surface is: did the product domain perform? Delivery metrics — velocity, throughput, story points — are inputs to the conversation, not the primary accountability surface. A product team that shipped slowly but moved its outcome metrics meaningfully is performing. One that shipped constantly but did not move the metrics is not.
Evaluation dimensions: product outcome metrics specific to the domain (conversion, retention, reliability, adoption, revenue contribution); execution surface health (is the automated layer governed, monitored, and improving?); and decision quality (are the team's product decisions traceable, well-reasoned, and aligned with organizational strategy?).
Diagnostic questions for a CTO quarterly review:
-
Are the product domain's outcome metrics moving in the right direction, and does the team understand why?
-
Is the team's execution surface — including its automated layer — owned, governed, and improving?
-
Is the team spending its human capacity on judgment and design, or is it absorbed in managing execution gaps?
-
Can the team articulate the execution mode of each significant workflow it operates?
Evaluating platform teams.
Platform teams are evaluated on platform fitness and the health of the infrastructure they provide — not on delivery output. Three dimensions matter: reliability of the infrastructure they own, adoption and satisfaction of the internal teams who depend on it, and the rate at which the platform's capability is improving over time.
A useful proxy is the inverse of the tax they impose on product teams. If product teams are spending significant engineering time working around the platform — building their own infrastructure, maintaining workarounds, or waiting on platform dependencies — the platform team is not performing, regardless of what it shipped.
Evaluation dimensions: infrastructure reliability (uptime, latency, incident rate); internal adoption and satisfaction (are product teams using the platform effectively, and what friction do they experience?); platform capability growth (is the platform's execution surface expanding in ways that increase product team capacity?); and governance quality (are the systems the team owns monitored, documented, and operating within their defined execution modes?).
Diagnostic questions for a CTO quarterly review:
-
Are product teams spending engineering capacity working around the platform, and if so, why?
-
Is the platform team stewarding its infrastructure — actively governing, monitoring, and improving what it owns — or is it primarily reactive?
-
Is the platform's capability growing in ways that expand product team execution capacity?
-
Is the platform team being pulled into delivery work that belongs to product teams? If so, what structural condition is causing that?
Evaluating automation capability groups.
Automation capability groups are evaluated on organizational automation maturity — not on individual automation outputs. They do not ship products. They do not build automation on behalf of other teams. A capability group that is doing the work for other teams is underperforming. One that is raising the floor of what other teams can do on their own is succeeding.
Three dimensions: the percentage of the organization's execution surface that is governed and owned; the quality and consistency of automation governance across teams; and the rate at which teams are successfully designing, operating, and improving their own automated execution layers.
Evaluation dimensions: execution surface coverage (what proportion of the organization's automated execution is governed and owned?); governance quality (are automation standards applied consistently?); team capability growth (are teams becoming more capable at designing and governing their own automation?); and incident rate from ungoverned automation (is it decreasing?).
Diagnostic questions for a CTO quarterly review:
-
What proportion of the organization's automated execution surface is currently ungoverned? Is that proportion decreasing?
-
Are consistent standards being applied when teams build and deploy automation?
-
Is the capability group doing work that other teams should own, or raising their capability to own their own execution surfaces?
-
When the capability group reviews automation designs, what proportion meet governance standards on first review? Is that proportion improving?
Evaluating execution pods.
Pods are evaluated on problem resolution and clean dissolution — not on permanence or throughput. The evaluation is binary at its core: did the pod resolve the execution problem it was assembled to address, and was the result handed off cleanly?
Evaluation dimensions: problem resolution (is the solution validated?); handoff quality (was the execution pattern handed to the correct permanent team with appropriate documentation, governance model, and ownership assignment?); and dissolution discipline (did the pod dissolve as designed?).
Diagnostic questions at dissolution:
-
Is the execution problem resolved and stable enough to operate within a permanent team?
-
Has the capability group reviewed and approved the governance model?
-
Is the receiving team clear on what they are inheriting, at what execution mode, and with what monitoring in place?
-
Is the pod actually dissolving, or is there organizational pressure to keep it together?
Archetypes Across the Growth Curve
The four archetypes describe the mature shape of a hybrid organization. They do not describe a prerequisite structure that must exist before the framework applies. In a growing organization, the archetypes are a design target — the direction the organization is moving — not an immediate requirement.
At every stage of growth, there will be overlaps. That is not a failure of the model. It is an expected condition that the design must account for explicitly.
The engineer counts that follow are directional, not deterministic. The signal that matters is structural pressure — not the number itself.
Early stage — one team carries everything.
At small scale — typically under thirty engineers — a single team carries product, platform, automation, and exploratory work simultaneously. The archetypes are not structurally distinct. But archetype thinking is still useful: even within a single team, it is possible to assign accountability in ways that mirror the archetype distinctions. Two engineers own the infrastructure layer and are accountable for its fitness. One person owns automation standards and reviews new automation before it is deployed. Product outcomes are tracked separately from platform reliability.
The archetypes exist as accountability roles within a single team, not as separate teams. The distinctions prevent the most common failure of early-stage organizations: the infrastructure layer consistently losing to product delivery pressure when both live with the same team and neither has a named owner.
Growth stage — the first separations.
As the organization scales — typically between thirty and one hundred engineers — the first natural separation is product from platform. The signal is clear: when the infrastructure layer is demanding enough that it competes with product delivery for the same engineers' attention, the separation has become structurally necessary. Continuing to hold both in the same team produces a predictable outcome — the platform degrades, because delivery pressure always wins in the short term.
The automation capability group often emerges informally at this stage — a senior engineer who sets standards and reviews automation design before it is deployed — before it becomes a named team. The informal version is acceptable as a transitional state, provided the accountability is explicit. The organization should be able to name the person carrying that accountability, even if they are not yet a dedicated function.
Execution pods may appear as informal working groups. The discipline of explicit dissolution conditions is particularly important here — working groups have a strong tendency to persist and accumulate scope. Building the dissolution condition into every pod-like structure is a design habit worth establishing early.
Scale stage — all four archetypes become distinct.
At scale — typically above one hundred engineers — all four archetypes become structurally necessary. The cost of overlap has become visible: platform work degrades when delivery dominates the same team; automation governance breaks down without a dedicated capability function; exploratory work never completes because pods were never formally separated from ongoing delivery.
The signals that each separation has become necessary:
Product from platform: product teams are spending significant engineering capacity managing infrastructure they should be consuming as a service. The infrastructure layer has accumulated technical debt that no team has the mandate or capacity to address.
Platform from automation capability: the platform team is building and owning automation on behalf of product teams rather than enabling them to own their own. The governance model is inconsistent across teams because no single function owns it.
Execution pods from ongoing delivery: exploratory execution work is being absorbed into product team backlogs, competing with delivery commitments and never reaching resolution. The organization has no structured mechanism for addressing bounded execution problems without permanently restructuring a team.
Each separation is a structural response to a governance failure that has become visible. The failure always precedes the structural correction — the question is whether the organization responds to the first clear signal or waits until the cost is significantly higher.
The Failure Mode
The failure mode specific to structural archetypes is archetype collapse — when the distinctions between team types erode and every team is treated as a variant of the same basic unit.
It shows up most often in three patterns. Platform teams are drawn into product delivery work — either because product teams treat them as a shared engineering resource, or because the organization evaluates all teams on delivery velocity. When this happens, the infrastructure layer degrades. Nobody is stewarding the platform, because the platform team is too busy shipping features for product teams to govern what it owns.
Product teams accumulate infrastructure responsibilities they were never designed to carry — because the platform team is either absent, insufficiently capable, or focused on delivery work. The product team ends up owning both the product outcome and a portion of the infrastructure, with unclear accountability for both.
Execution pods become permanent. The problem they were assembled to solve is technically resolved, but the team persists — either because the organization defaults to permanent structures, or because dissolving the team is politically difficult. The result is a team that persists after its purpose has ended.
In each case, the structural design has drifted from the execution model — and the drift produces exactly the kind of ownership confusion, accountability diffusion, and scaling friction that the archetypes were designed to prevent.
The Structural Correction
Maintaining archetype integrity requires three things: explicit team typing at the point of formation, evaluation models aligned to the archetype rather than to a universal delivery metric, and a periodic design review that confirms the type still matches the execution model.
When a team is formed, its archetype is declared as a design commitment. A product team is accountable for outcomes. A platform team is accountable for infrastructure capability. An execution pod has a defined problem scope and a dissolution condition. An automation capability group has an organizational scope, not a product scope. These commitments shape the charter, the evaluation model, and the relationship to the rest of the organization.
In a growing organization that cannot yet form all four archetypes as distinct teams, the accountability distinctions should be made explicit within the existing structure. Name the person accountable for platform fitness. Name the person who reviews automation governance. Build dissolution conditions into every working group that resembles a pod. The archetypes can exist as accountability roles before they exist as teams — what matters is that the accountability is explicit, not that the org chart has four boxes.