Skip to content
Resources
Program Operations
Governance

Governance

Most decisions stay exactly where they already are, with whoever’s closest to the work. This page is mainly about the smaller set of cases that cross team lines: when it’s worth looping others in, and how we keep track of what was agreed so nobody has to hold it in their head.

Decision-making principles

Theseus is a paved path used by every modular-service team, so most calls should still sit with whoever is closest to the work. Nearly every decision comes down to one question: does this touch something another team relies on?

No The owning team decides and ships it. There’s no governance step.
Yes Bring in whoever made or relies on that commitment, then record a Decision in the change log.

What counts as something another team relies on: the surface other teams build against — the CLI, the manifest schema, generated artifacts — rather than a component’s internal implementation. In practice that means a breaking change to the Fairway manifest schema, a new default that changes generated output, a platform-binding boundary, or a milestone commitment made to a requesting team. Whoever made or relies on that commitment should be part of the conversation, not informed after the fact. This is the same bar the change log already uses for a Decision entry.

Flag misalignment early and often, as soon as it shows up rather than waiting to see if it resolves on its own. The DRIs on each side try to work it out between themselves first; if they can’t reach alignment, it comes to program leadership, who works with them to resolve it. Don’t sit on it for days or weeks hoping it settles.

Recording decisions: the change log

Theseus doesn’t keep a second decision log on this page. The change log is the system of record. Cross-team alignment decisions ship there as entries tagged Decision, each carrying:

  • a status
  • a DRI
  • the stakeholders who were present

If a decision clears the bar above, it gets a change log entry using the existing template (hugo new content changelog/YYYY-MM-DD-your-slug.md, or copy the front matter of a recent Decision-tagged entry), not a new file or format. This page’s job is only to define when an entry makes sense and who needs to be in the room before it’s written.

Go/No-Go: Pilot and GA launches

Go/no-go review applies to Pilot and GA launches specifically, not the earlier planning stages.

In the few weeks leading up to a Pilot or GA date, go/no-go becomes a standing item on the existing execution weekly meeting rather than a separate sync. The team confirms that everything the roadmap defines for that launch has actually been delivered, and that any risk it’s choosing to accept has been explicitly called out rather than left unspoken. Those answers go into a go/no-go doc, which the exec sponsor and program leadership review to give sign-off; they don’t need to sit in on the weekly meeting itself.

A no-go resets the target date and requires a new review before the next attempt.

Before launch: capability intake

Earlier in a capability’s life, before either of these launch reviews, new capability requests go through the existing intake path: submit a request, team reviews, accepted requests join the platform backlog.

This page adds the context behind that step — who “the team” is and what makes a request get accepted — rather than re-describing the intake mechanic itself.

Related

We don’t keep a separate decision log here; the change log already is one. See Recording decisions above.

Last updated on
Execution Model