Multi-Team Governance

Some knowledge has no single owner. A runbook for handling a client escalation that spans sales, engineering, and client success. A process for launching a new product that involves marketing, legal, and operations. A compliance framework that touches every department. This content is too important to leave ungoverned, but too cross-cutting to assign to a single steward without creating boundary disputes.

Multi-team governance is the pattern for knowledge that spans organizational boundaries. It requires explicit coordination mechanisms rather than relying on organic collaboration — because organic collaboration between departments with different priorities and different definitions of "urgent" produces documentation that is last reviewed by whoever felt most urgently about it most recently.

1. Identify Cross-Domain Content Content is cross-domain when: it references processes owned by more than one team, an inaccuracy in it affects more than one department's operations, or it requires subject matter expertise from more than one domain to verify its accuracy. Audit for cross-domain content by checking which items have topic facets spanning multiple domain areas. These items are the ones most likely to have ambiguous ownership and least likely to have been reviewed recently.
2. Assign a Lead Steward with Contributing Reviewers Every cross-domain item has one lead steward and a list of contributing domain reviewers. The lead steward is the tie-breaker and the accountability holder: if the review is not happening, the lead steward is the person who is accountable. Contributing reviewers provide domain expertise validation: each reviewer confirms the accuracy of the sections within their domain expertise. The lead steward confirms the overall coherence and routes to contributors for their sections.
3. Governance Council for High-Stakes Cross-Domain Content For content that is both cross-domain and high-consequence — a compliance framework, a company-wide incident response procedure, a client contract template — a governance council provides oversight. The council is small (3–5 people, one per affected domain) and meets quarterly. Agenda: review cycle status, open changes, conflict resolutions, and deprecation decisions. The council does not review content line by line — it provides governance oversight and makes calls when stewards cannot resolve disagreements.
4. Conflict Resolution for Cross-Domain Disagreements When domain reviewers disagree about content accuracy, a conflict resolution process must exist before the conflict arises — not improvised when it happens. The process: the lead steward attempts facilitation. If unresolved, the central knowledge function mediates and proposes a resolution. If still unresolved, the governance council (or, for non-council content, the relevant team leads) makes the final call. Document the resolution and the reasoning. Undocumented conflict resolutions get relitigated every time a new reviewer joins.

# Cross-domain content ownership schema
cross_domain_items:
  - id: "kb-00147"
    title: "Client Escalation Response Runbook"
    content_type: runbook
    topic_facets: ["Client Success", "Engineering", "Sales Process"]
    governance_type: cross_domain

    lead_steward:
      person: "riley.morgan"
      domain: "Client Success"
      rationale: "Client-facing outcome is the primary concern"

    contributing_reviewers:
      - person: "alex.chen"
        domain: "Engineering"
        sections: ["Technical triage steps (Steps 4–7)"]
        review_authority: "Signs off on technical accuracy only"
      - person: "sam.torres"
        domain: "Sales Process"
        sections: ["Executive communication steps (Steps 8–9)"]
        review_authority: "Signs off on sales/client communication framing"

    review_cadence_days: 90
    last_reviewed: "2026-01-10"
    next_review_due: "2026-04-10"
    governance_council: null    # Not high-stakes enough for formal council

  - id: "kb-00201"
    title: "Company-Wide Incident Response Framework"
    content_type: article
    topic_facets: ["Infrastructure", "Security", "Compliance", "Client Success"]
    governance_type: council

    lead_steward:
      person: "alex.chen"
      domain: "Infrastructure"
      rationale: "Technical infrastructure incidents are primary scope"

    governance_council:
      members:
        - "alex.chen (Infrastructure)"
        - "sam.torres (Compliance)"
        - "riley.morgan (Client Success)"
        - "dana.kim (Security)"
      meeting_cadence: quarterly
      last_meeting: "2026-01-20"
      next_meeting: "2026-04-20"

    review_cadence_days: 90
    last_reviewed: "2026-01-20"   # Aligned to council meeting
    next_review_due: "2026-04-20"