Programming Governance: Templates, Versions and the House Standard in a Coaching Team

A coaching business with one coach does not need programming governance, because the method lives in one head and the head is consistent with itself. The moment a second coach starts building programs from the house method, every template acquires a second author, every exercise a second opinion, and within a quarter the clients on opposite sides of the team are training to visibly different products. Programming governance for a coaching team is the rule book that sits between those outcomes: who changes the templates, how versions reach clients, and how much each coach is allowed to deviate.

The standard itself is the documentation guide's territory, and the programming standard document it already wrote is the input this page governs. What this page adds is the governance in operation: the change rule, the version flow and the deviation rule that keep a house method coherent while leaving room for the individualised coaching the clients are paying for.

What is programming governance in a coaching team?

Governance is four rules over one shared artefact: the template set, which is the house method made concrete as templates every coach uses; the change rule, which says who may edit a template and through what review; the version flow, which says how a template change reaches clients without breaking programs mid-stream; and the deviation rule, which says what personalisation a coach may make on top of a template and how deviation is reviewed. The goal is not uniformity. It is bounded personalisation, and governance is what draws the boundary.

The tension, named honestly

Two failure modes sit at opposite ends of a dial, and both are real. Standardise everything and the method suffocates the coaching: a client with an old knee receives a template that did not know they existed, and the coach, forced to choose between the standard and the client, quietly stops following the standard. Leave everything to the coaches and the brand dissolves: three coaches build three different products, clients compare notes, and the business sells a house method it no longer houses. The governance rules live in the middle, and their shape is the honest finding of this page: what gets governed is the anatomy of the program, while what stays free is the personalisation inside it.

What that distinction means in practice is a question of kind, not degree. Load, progression pace, exercise substitutions for equipment or injury, and the weekly shape of a block are the coach's judgement, because individualisation is the product. What the template fixes is the substance of the method: the movement patterns a block must cover, the structure of a session, the check-in points, the reasons a stage exists. A coach personalising inside the pattern is delivering the method. A coach rebuilding the pattern is writing a new method under the old brand, and the difference between those two is exactly what the deviation rule is for.

The change rule: who edits the house templates

The template set is a shared artefact, and shared artefacts die by uncontrolled editing. The change rule needs three parts, all writable in a paragraph: who may edit the templates directly, how a proposed change is made, and who decides adoption.

A workable shape for a coaching team: coaches propose template changes rather than making them in place, the owner or head of coaching reviews proposals against the written programming standard, and adopted changes are made once, centrally, in the shared template so every future client inherits them. The review does not slow the method down, and it does something more valuable: it stops the house templates from becoming a private library that each coach forks for themselves. When a change also touches the written standard itself, the same adoption step updates the document, because a template that has drifted from its standard is a disagreement nobody has had out loud. The quarterly document review the documentation guide already runs is where those two artefacts get reconciled.

The version flow: how changes reach clients

A template change is not an instruction that clients rebuild their week. The version flow answers the only dangerous question in template governance: what happens to clients already running the old version?

The common convention, and the shape worth writing down in a team: clients mid-cycle finish on the version they started, new clients and new cycles pick up the adopted version, and no in-flight program is silently rewritten underneath a coach or a client. This maps onto how shared templates behave in practice, where a client's program is built from the template but then runs as a live record of their own; every shared-template workflow in the product starts by cloning rather than mutating, which is exactly the property a version flow needs. The rule to govern is the timing: a change adopted mid-cycle takes effect at the client's next cycle, not mid-progressions, because progressions restarted mid-flight are how template changes get blamed for what they did not do.

The deviation rule, and how deviation gets reviewed

Deviation is allowed, encouraged even, and bounded. The deviation rule names what a coach may change on top of a template without anyone's sign-off, and what requires a conversation: substitutions forced by equipment, injury flags or the client's schedule sit inside the allowance; changes to block structure, to the method's progression logic, or to the outcomes a stage targets sit outside it and go back through the change rule instead.

Deviation gets reviewed through the quality system rather than through trust. The QA system for a coaching team already samples real delivery on a monthly cadence, and a program artefact read in a QA sample answers a governance question directly: did the coach personalise inside the pattern, or rewrite the pattern? The review load is light arithmetic: if a month's sampling flags a handful of deviations per coach and each review costs a few minutes, the load is small enough to sit inside the span budget our guide to span of control already prices. The load is also a signal in its own right: a coach whose samples constantly read as deviations is either inventing their own method or running clients whose needs the template set does not cover, and both findings route somewhere useful, the second one straight into the change rule.

What each part is for, and what it is not

The four rules survive contact with a real team only if their limits are written beside them. The change rule is not a veto on coaches improving the method; it is a single door through which improvements enter, so the method improves faster than a suggestion box and slower than a solo coach's whim. The version flow is not bureaucracy for small edits; a load tweak inside a session needs no process, and governing trivia is how governance earns contempt. The deviation rule is not a script for programming decisions: what exercises to pair or how to periodise is coaching method, and the reference material for that belongs to a coach's own development, not to a governance page. What belongs here is only the boundary, and every boundary the house standard already drew.

Where the capability that carries all of this is documented is the program builder definition and the program-builder feature page, which own the mechanics: shared templates, the shared exercise library and clone-and-personalise workflows. This page has deliberately not walked through any of it, because the governance of a shared standard and the capability that hosts it are different documents for different moments. The operating rhythm within which the review and the change decisions run is the operating system's weekly cadence, and the onboarding that hands a new coach into the standard is its own subject in this series.

Frequently asked questions

What is programming governance in a fitness business?

The four rules over a team's shared programming: a template set that makes the house method concrete, a change rule for who edits templates and how, a version flow for how changes reach clients, and a deviation rule for the personalisation coaches make on top. Governance draws the boundary between the method the brand sells and the individualisation the client buys.

How much should coaches be allowed to deviate from house templates?

Wherever the client's body and schedule force it, and not where the method's structure is defined: load, exercise substitutions, equipment, and progression pace within the block are coaching judgement, while block architecture and progression logic belong to the house standard. Where the boundary sits for your method is a written decision, reviewed through the QA sample rather than policed in conversation.

Who should be allowed to change program templates in a coaching team?

One reviewer with an adoption decision, and a proposal path everyone can use. Coaches propose against the written standard, adoption is made centrally in the shared template set, and every future client inherits the change. The alternative, coaches editing their own copies, is not speed. It is the quiet fork that becomes three methods wearing one brand.

How often should program templates be reviewed?

Alongside the quarterly document review the documentation guide already schedules, with mid-cycle changes reserved for corrections rather than improvements. Template changes take effect at the next cycle boundary for clients mid-program, which keeps the version flow honest and the blame arithmetic clean.

The governance structures, review cadences and deviation examples in this article are illustrative patterns for a team's own method, not benchmarks or programming advice. No workout, periodisation or exercise-selection guidance appears here by design. This article is a guide for your own decisions, not business or financial advice.