Operating Model
How the platform grouping is staffed and how its teams interact. For the team map and dependencies, see the Platform Grouping overview.
Interaction Modes
Team Topologies defines three interaction modes — X-as-a-Service (consume without collaboration), Collaboration (work together temporarily to solve a problem), and Facilitating (help another team improve capability). Collaboration is always time-boxed; the goal is to transition to X-as-a-Service once the consuming team is self-sufficient.
| Team | Steady-State Mode |
|---|---|
| Logos | X-as-a-Service |
| Corpus | X-as-a-Service |
| Pneuma | X-as-a-Service |
| Arche | X-as-a-Service |
| Ekklesia | Facilitating |
| Techne | Facilitating |
X-as-a-Service · Collaboration · Facilitating
Cognitive Load
Team Topologies distinguishes three types of cognitive load — intrinsic (inherent domain complexity), extraneous (friction from poor tooling), and germane (productive expertise-building). The platform is designed to eliminate extraneous load through shared automation (Arche, Techne), so each team's cognitive budget is spent entirely on intrinsic and germane load.
| Team | Working Domains | High Intrinsic Domains |
|---|---|---|
| Ekklesia | Within limit — 1 / 4 | Within limit — 0 / 3 |
| Techne | Approaching — 3 / 4 | Within limit — 0 / 3 |
| Arche | Within limit — 3 / 4 | Within limit — 1 / 3 |
| Logos | At limit — 4 / 4 | Within limit — 0 / 3 |
| Corpus | At limit — 4 / 4 | Within limit — 1 / 3 |
| Pneuma | Over limit — 6 / 4 (target ≤4 / 4) · ADR → | Over limit — 4 / 3 (target ≤3 / 3) |
Team Capacity
Internally, each platform engineer specializes in one team's context; externally the platform grouping presents one coherent interface to stream-aligned teams, the Nomos Agent — consistent tooling, documentation, and services regardless of which team delivers them.
Headcount is derived from the cognitive load analysis. When operating within capacity, a team requires one platform engineer to maintain and evolve its scope. A team approaching or at its limit is a candidate for additional capacity or scope reduction. A team that exceeds its target is the highest priority for intervention — either a second engineer, scope reduction, or tooling investment to lower extraneous load.
Platform Lead
A single Platform Lead spans all teams. This role does not belong to any one team — it exists above them. On this platform, the Platform Lead also serves as the Product Manager, owning both the technical direction and the platform roadmap.
Responsibilities:
- Owns the platform roadmap and prioritizes work based on stream-aligned team needs
- Interfaces with stream-aligned team leads and engineering leadership to inform that roadmap
- Owns cross-team dependency sequencing (Logos → Corpus → Pneuma)
- Ratifies Architecture Decision Records (ADRs) across all teams
- Unblocks cross-team decisions that no single platform engineer can resolve
- Allocates capacity across staffed teams based on platform demand
Platform Engineers
Each staffed team starts with one platform engineer who owns the team's context end-to-end. Teams can scale beyond one engineer as cognitive load demands — the cognitive load analysis is the guide for when to add capacity.
| Team | Min. Engineers | Role |
|---|---|---|
| Logos | 1 | Owns org structure, identity, GitHub, and Datadog team management |
| Corpus | 1 | Owns GCP projects, shared VPC, state buckets, and workload identity |
| Pneuma | 1 | Owns GKE clusters, service mesh, policy enforcement, and cluster add-ons — currently over its cognitive-load target, candidate for a second engineer |
| Arche | — | Innersource — no dedicated engineer |
| Ekklesia | — | Innersource — no dedicated engineer |
| Techne | — | Innersource — no dedicated engineer |
Total: 4–5 engineers + 1 Platform Lead (minimum staffing — scale per cognitive load analysis)
Innersource Model
Arche, Ekklesia, and Techne operate without dedicated engineers. Instead, they run as innersource repositories — open for contribution from any engineer on the platform or from stream-aligned teams.
How it works:
- Any engineer may open a pull request to an innersource repo
- Platform engineers from staffed teams (Logos, Corpus, Pneuma) serve as code owners and reviewers
- The Platform Lead has final approval authority on structural or architectural changes
- Stream-aligned teams can unblock themselves by contributing fixes or enhancements directly, rather than filing tickets and waiting
This model distributes platform knowledge across the organization, reduces bottlenecks on the staffed teams, and ensures innersource repos evolve with the needs of their consumers rather than on a centralized backlog.