Zeta’s organizational design is a deliberate Reverse Conway Maneuver. We shape our physical teams specifically to produce our target system architecture: assembled Customer Products derived from reusable, compounding core assets.
To do this at scale, Zeta aligns its durable engines and delivery squads with the Team Topologies model (Skelton & Pais) to limit cognitive load, make inter-team interfaces explicit, and ensure a fast flow of change.
1. Organizing for Cognitive Load & Fast Flow
Traditional organizations scale by adding middle management and siloed departments. This introduces massive human-to-human coordination friction. In an agent-augmented world, if synchronous human reviews remain in the critical path, waiting on humans becomes the slowest edge in the execution graph.
Zeta's socio-technical architecture is designed to shrink cognitive load on our delivery squads, freeing their capacity for customer-specific problem-solving:
- Intrinsic Load (Essential difficulty): Offloaded to our specialized Platform and Complicated Subsystem teams, who manage the deep complexity of transactional engines, cloud networks, and financial processing networks.
- Extraneous Load (Accidental/tooling friction): Offloaded to our ERE and EWE automation platforms, standard solution archetypes, and pre-modeled cookbooks.
- Germane Load (Value-adding focus): Retained by our front-line squads to focus purely on customer requirements, integration parameters, and local configurations.
2. Complete Classification of Org 8.0 Units
Every durable unit and ephemeral execution squad in Zeta is assigned an explicit, contract-bound team topology. Their communication paths are governed by strict interaction modes: X-as-a-Service (XaaS), Collaboration, or Facilitating.
| Org 8.0 Unit | Team Topology | Fracture Plane | Primary Interaction Mode(s) |
|---|---|---|---|
| Customer Product (CP) / Studio Squads | Stream-Aligned | Per Customer / SOW | Consumes Platforms/Tooling via XaaS; Collaborates during Discovery |
| Product Line Squads (Tachyon, etc.) | Platform (Product Plane) | Per Product Line | Provides core assets via XaaS; Collaborates during inner-source loops |
| ERE / EWE Platform Teams | Platform (Delivery Platforms) | Per Automation Tooling | Provides self-service tooling via XaaS; Collaborates during pilots |
| SRE Operations — Runtime Foundation | Platform (Run infrastructure) | Per Infrastructure | Provides runtime sites and deployment pipelines via XaaS |
| Solution Archetype & Domain Owners | Enabling | Per Archetype Domain | Facilitates; provides standard blueprints and cookbooks via XaaS |
| Academy: Training & Certification | Enabling | Per Role / Capability | Facilitates; provides certified role-readiness catalogs via XaaS |
| Knowledge Engineering & Stewards | Enabling | Per Domain Knowledge | Facilitates; curates patterns and updates the Work Catalog |
| Platform Architecture Council (PAC) | Enabling (Governance) | Cross-cutting Design | Facilitates during practice; acts as a Gate during governance |
| Verification Squad (AVA-led) | Complicated Subsystem | Per Specialism (Verification) | Collaborates on acceptance criteria; provides certification-as-a-service |
| SRE Operations — Site Assurance | Complicated Subsystem | Per Run-time Posture | Facilitates; provides compliance/DR audits via XaaS |
| SRE Operations — Platform Operations | Complicated Subsystem | Per Core Platform | Provides multi-tenant central platform operations via XaaS |
| Processing Operations CoE | Complicated Subsystem | Per Financial Domain | Provides clearing, recon, and network operations via XaaS |
| Processing Ops — Product Compliance | Complicated Subsystem | Per Regulatory Domain | Facilitates; provides financial regulatory audits via XaaS |
3. Team APIs and the Thinnest Viable Platform (TVP)
In Team Topologies, teams must expose an explicit, stable Team API—the contract through which other teams consume their capabilities without synchronous alignment meetings:
- The TVP Boundary: Our Platform teams operate under the Thinnest Viable Platform (TVP) principle. They build the minimum self-service tooling required to accelerate stream squads without over-serving or dictating how they operate. This maps directly to the Product Line Engineering (PLE) "what's in the box" boundary.
- Platform APIs & SDKs: Standard platform codebases expose well-defined variability parameters and SDK extensions.
- The Inner-Source SLA: Product Line squads expose a stable Team API for code contributions, operating under a strict 48-hour SLA to review and merge inner-source pull requests.
- ERE & EWE Tooling endpoints: ERE provides self-serve bootstrap scripts and proposal agents; EWE provides automated billing interfaces and SLA telemetry dashboards.
4. Operational Symmetry: The Build vs. Run Planes
The "assembly" pattern does not stop at Transfer. To maintain high operating leverage and prevent duplication, Zeta enforces a strict, self-similar symmetry across both the Build and Run planes:
| Pattern Role | Build Plane (Assembly) | Run Plane (Operations) |
|---|---|---|
| Reusable Centralized Layer | Platform Product Line Squads (Platform topology; provides core assets) |
SRE Platform Operations (Complicated Subsystem; multi-tenant XaaS) |
| Bespoke Per-Customer Layer | Studio Squads (Stream-Aligned; builds custom code) |
SRE Studio Product Operations (Stream-Aligned; runs customer's custom apps) |
| Unified Assembler & SLA Owner | Customer Product Squads / EOs (Assembles Customer Product) |
Engagement Win Teams (EWT) (Composes and operates the running SLA) |
| Coherence and Quality Authority | Engagement Architects (EA) / AVAs (Define and verify the build assembly) |
Engagement Win Teams (Own the end-to-end operated service SLA) |
5. Strategic Deviations and Reconciliations
To suit the highly regulated, enterprise-scale reality of global transaction banking, Zeta's socio-technical model selectively deviates from canonical Team Topologies. These variations are bound by strict reconciliations:
5.1 Ephemeral Stream-Aligned Squads
- Deviation: Canonical Stream-aligned teams are long-lived; Zeta's Customer Product squads are ephemeral, forming around an active SOW and disbanding after ~2 years.
- Reconciliation: The true flow unit is the customer's Engagement, which is long-running. Team-first continuity is preserved off-squad by housing all practitioners permanently in vertical Chapters (career homes), maintaining a codified Work Catalog, and deploying pre-integrated HATs that carry collective context.
5.2 Roles Overlaid on Squads
- Deviation: Team Topologies discourages matrixed roles; Zeta uses a strict dual-axis model.
- Reconciliation: Key roles—such as Engagement Owners (EO) and Engagement Program Managers (EPM)—serve as the Engagement's unified Integration API to the customer, coordinating across squads. Engagement Architects (EA) and AVAs act as peer architects who define and verify system boundaries, maintaining clean interfaces while vertical Chapters protect craft standards.
5.3 Verification as a Dedicated Complicated Subsystem
- Deviation: Canonical Team Topologies discourages separate test/QA teams and mandates embedding testing inside the stream.
- Reconciliation: Zeta's separate, AVA-led Verification Squad is structurally necessary because:
- The assembly-wide system-under-test boundary spans multiple squads' output, which no single functional squad owns.
- The AVA holds a non-overridable, independent release-block authority that requires structural independence from delivery management (EPMs). We prevent hand-off latency by enforcing tight, continuous EA \(\leftrightarrow\) AVA Collaboration from the Discovery phase. On small engagements, this subsystem collapses entirely into the EA/AVA roles, eliminating team overhead.