Sustainable operating model

Problem

The connector dashboard pack catalog is a living product—connectors change their schemas, Fivetran adds new connector features, user expectations evolve, and packs need updating. Currently, there is no documented operating model for who maintains packs, how support tickets are triaged, what the release cadence is for pack updates, or how new connector packs are prioritized. Without a sustainable operating model, maintenance will fall to whoever happens to be available, support requests will go unrouted, and the release process will be ad hoc. This leads to stale packs, inconsistent update quality, and unsustainable load on the engineering team.

Context

• A launch can succeed briefly even with fuzzy ownership, but connector-specific dashboard packs and KPI narratives for Fivetran sources will drift quickly without a clear model for maintenance, triage, and decision-making.
• This task is about defining who owns backlog hygiene, review standards, incidents, documentation, and the cadence for future improvements.
• Expected touchpoints include dashboard pack YAML, dbt/example assets, connector fixtures, and quickstart docs, runbooks, planning docs, and team processes that currently rely too heavily on shared memory.

Possible Solutions

• A - Let the current contributors coordinate informally: low overhead, but it becomes brittle as scope and contributors grow.
• B - Recommended: define a lightweight operating model with named owners and cadences: make maintenance, incident response, prioritization, and release decisions explicit.
• C - Centralize all ownership in one person or team indefinitely: clearer in the short term, but usually unsustainable and a bottleneck.

Plan

1. Map the recurring operational decisions around connector-specific dashboard packs and KPI narratives for Fivetran sources and identify where ownership, handoff, or cadence is currently unclear.
2. Document the operating model: owners, review loops, incident or support handling, documentation upkeep, and backlog-management expectations.
3. Align the model with the actual command/docs/test surfaces that people use day to day so it is operational rather than aspirational.
4. Publish the model in the relevant planning/runbook surfaces and refine it after one real cycle of use.

Implementation Progress

Review Feedback

• [ ] Review cleared