One Page Summary

Acropolis — Initial Operating Model (Team One-Pager)

This is our initial operating model for how we organize and run Acropolis. It is meant to create clarity, speed, and autonomy while keeping delivery predictable. We should treat this as a starting point—we will iterate as we learn what works best for the team and the program.

Why we’re doing this

Acropolis is a large, multi-functional effort with real external milestones and many stakeholders. The goal of this model is to:

keep decisions close to the work,
reduce waiting and approval loops,
surface risks early,
and maintain a reliable delivery cadence.

Roles and who’s in them

Acropolis Team Lead: Chris
Project Leader: Leonard
Delivery: Anita
Architect: Paul
Quality Lead: Martin
Reliability Lead: (TBD / assigned as needed)
Product Manager: Carlos
Comms (Community Communications): Rupert
Formal Methods: Ramsay
SRE: Jon

Program Leadership Core

Chris + Leonard + Paul form the Program Leadership Core.

What it does: keeps the program aligned and healthy by handling exceptions (risks, major tradeoffs, decisions that cross boundaries), while avoiding day-to-day centralization.

What it is not: it’s not a gate you need to go through for normal execution.

How we want decisions to work

Our default is: decide at the lowest competent level and move forward with clear intent.

A simple pattern we’ll use is the intent statement:

“My intent is to ___ because ___. Constraints are ___. Success looks like ___.
I’m proceeding unless there’s a blocker by ___.”

This is a lightweight way to keep autonomy high while maintaining alignment.

When to escalate to the Core (boundaries)

Most decisions should not require escalation. We escalate when something meaningfully changes the program shape or risk posture. Examples include:

a milestone may slip by more than ~2 weeks
a change impacts cross-stream interfaces or architectural contracts
an externally visible behavior or API contract changes
increased correctness/security/consensus risk
increased operational risk (SLO/perf/regression, data-loss risk)
budget/headcount changes
any change that creates or modifies a public commitment
a stop-the-line gate is triggered (Quality / Reliability / Formal Methods)

If you’re unsure, raise it—better early than late.

Cross-functional coordination

We’ll use a weekly cross-functional forum to keep gates, dependencies, and external milestone needs synchronized.

Cross-Functional Leaders Forum (weekly):
- Lead: Anita (Delivery)
- Execution Integrator: Leonard (Project Leader)

This forum is where quality gates, reliability gates, assurance scope, product acceptance, comms commitments, and dependency readiness are coordinated and translated into executable work.

What each role is “here to own” (at a high level)

Project Leader (Leonard): planning cadence, backlog flow, milestone tracking, weekly updates
Delivery (Anita): dependencies/integration readiness, Intersect milestone acceptance artifacts, monthly status, exec briefings, offsites
Architect (Paul): architecture coherence and cross-stream interfaces
Quality (Martin): test strategy and release/milestone quality gates
Reliability (Jon): CI/DB, SLOs/SLIs, performance/operational readiness gates
Product (TBD): use case priority, acceptance criteria, customer feedback loops
Comms (Rupert): community communications, predictable updates, feedback intake
Formal Methods (Ramsay): targeted specs/assurance for high-risk areas

Cadence (kept intentionally lightweight)

Program Leadership Core: 2×/week, 30 minutes (exceptions only) led by Chris
Cross-Functional Leaders Forum: 1×/week, 45 minutes (exceptions only) led by Anita
Daily Developer Standups 3x/week, 45 minutes (outcomes) led by Leonard
Weekly async update: authored by Leonard, reviewed by Chris (until we have dashboards)
Monthly status update: authored by Anita, derived from weekly updates (until we have dashboards)