ZETA.ORG 8.0
View 4: Leadership & Partnership

03. Decision Rights and Arbitration

To maintain a high-velocity operating model, Zeta establishes strict boundaries of authority and clear, non-bypassable arbitration pathways to resolve cross-axis conflicts.


1. Primary Decision Rights

The following matrix defines which Partner roles hold final, non-bypassable decision authority over key enterprise processes:

Decision Domain Final Authority Holder Veto Power Holder Governing Council
SOW Pricing & Signing GTM Partner Engagement Partner (Delivery feasibility) Engagement Readiness Council (ERC)
Platform Core Roadmaps Capability Partner PAC / Senior Partner (Platform Architecture) Platform Architecture Council (PAC)
Squad Staffing & Allocation PPM / Portfolio Management Competency Partner (Certification verification) C3M Council / PPM
Uptime & SRE Incident Veto Competency Partner (SRE CoE) None (Absolute operational sovereignty) SRE Site Assurance
Inner-Source Repatriation Platform Maintainers Capability Partner (P&L owner) Platform Architecture Council (PAC)

2. Standard Cross-Axis Conflict Scenarios & Arbitration

When objectives conflict across the horizontal (execution) and vertical (capability/talent) axes, partners must follow codified arbitration pathways rather than engaging in ad-hoc, relationship-dependent compromises.

2.1 Scenario A: GTM Partner vs. Engagement Partner (Bespoke Customer Requests)

  • The Conflict: A GTM Partner wishes to promise a major, non-standard software feature to a client bank to close a high-value subscription contract. The Engagement Partner objects because the feature cannot be configured using standard platform variability points and will require a high-cost, bespoke code fork.
  • The Arbitration Pathway:
    1. The feature request is formally submitted to the Platform Architecture Council (PAC) for a gap analysis.
    2. If the PAC determines the feature is a generic capability that belongs in the platform, the Capability Partner can choose to co-sponsor and fund its core R&D.
    3. If the PAC determines the feature is bespoke and cannot be generalized, the request is routed to the Engagement Readiness Council (ERC).
    4. The ERC either:
      • Vetoes the request and directs GTM to sell a standard solution.
      • Approves the request only under a high-margin, bespoke surcharge SOW, with the custom execution assigned to a dedicated Customer-Release team (EWT), ensuring the core Platform remains untouched.

2.2 Scenario B: Competency Partner vs. Engagement Owner (Practitioner Rotation)

  • The Conflict: A Competency Partner (Chapter Steward) wants to rotate a senior software engineer out of an active Customer Product squad to complete a mandatory certified platform training program or work on a core Product Line. The Engagement Owner (EO) objects, claiming that losing the engineer will cause the squad to miss an active SOW delivery milestone.
  • The Arbitration Pathway:
    1. The dispute is formally logged with the Portfolio Program Management (PPM) office.
    2. The PPM evaluates the active SOW risk against the Chapter's overall talent utilization metrics.
    3. If a certified, pre-integrated replacement HAT member is available in the reserve pool, the PPM schedules the rotation immediately, minimizing onboarding lag.
    4. If no replacement is available, the PPM structures a transition plan: the engineer's rotation is delayed by a maximum of 14 business days, and the Chapter Steward must provide dedicated, automated Agent support to the squad to offset the temporary capacity reduction.
    5. The C3M Council serves as the final arbitration endpoint if PPM cannot resolve the scheduling conflict.