TBM 390: Governance by Principle, Not by Template

John Cutler · email · 2025-11-23 source ↗ Reader 🖥️

Decision-Making Practices Explore / Expand / Extract Organizational Legibility Platform Engineering Sociotechnical Architecture Team Topologies

Governance should be built from first principles — context-specific risk management, accountability, evidence, and decision rights — rather than inherited from project/program templates and accounting-flavored false precision, because software investment is durable and dynamic rather than static and project-shaped; most organizations' governance is procedurally legitimate (defensible on paper) while failing the substantive test of actually serving investors, employees, and customers, and nothing in major governance frameworks (OECD, NIST, ISO 38500, etc.) actually requires projects or programs as the unit of governance.

practical · mixed — Written as a reply to a reader question, the piece is argumentative at its core (debunking the belief that accounting/governance frameworks require project-and-program structures) and expository in its second half (a twelve-point checklist, each with a named 'Example Mechanism', for adapting governance to product/platform-centric work).

Structure

Part	Role
Framing: a reader's question about whether detailed project/program coding is an accounting requirement	context
Project/program codes and allocations are governance mechanisms the company invented, not accounting categories GAAP/IFRS require	premise (myth-busting)
Even 'set in stone' external governance frameworks (Basel III, procurement rules) specify principles/outcomes, not internal structure; intention and defensibility matter more than mechanical adherence	evidence
The procedural-vs-substantive-legitimacy distinction, illustrated by the 'business case ritual that technically follows every rule but hurts everyone' narrative	evidence / core argument
Survey of major governance guidance (OECD, CIPFA/IFAC, ERM, NIST, ISO 38500, ISO 9001): none require projects/programs; durable units (capabilities, domains, platforms) can satisfy the same requirements (accountability, evidence, checkpoints, auditability)	evidence
Diagnosis of why companies still default to project-based governance (legacy frameworks, borrowed procurement models, fear/inexperience, false precision, program-team habit)	explanation
Observation that the mismatch also afflicts self-described 'product operating model' companies, not just legacy enterprises	evidence (scope-widening)
Two governing principles (adapt to context; software sits near the dynamic end of the optimization spectrum) plus a twelve-point checklist with named 'Example Mechanisms' for adapting governance to durable product/platform units	conclusion (prescriptive)
Conclusion: governance should be treated like a product built from first principles rather than inherited language and structures	conclusion

Key terms

Procedural legitimacy vs. substantive legitimacy
Procedural legitimacy is performative box-ticking — following every rule in a governance framework. Substantive legitimacy is the degree to which actions genuinely advance the intended policy goals (serving investors, employees, customers). An organization can have the former without the latter.
Governance mechanism (vs. accounting category)
Project/program codes, cost allocations, and similar precise-looking figures are internally invented sense-making models for governing investment decisions — not requirements that originate in or appear in actual financial statements (outside of capitalization).
Durable object
A governance/investment unit — capability, domain, journey, product line, problem space, or platform — that persists across years rather than having a fixed start/end like a project, and can be governed through the same mechanisms (KPIs, checkpoints, decision rights) projects use.
Explore → expand → extract
Applied here as a lifecycle a durable product/platform/capability moves through, each phase requiring different governance posture (loose bets and iteration in explore; stability and optimization in extract) — reusing Kent Beck's lifecycle-phase model as a governance-design input.

Propositions

explicitProject and program codes exist because companies invented them for internal governance purposes, not because GAAP or IFRS accounting standards require them; financial accounting standards concern themselves only with revenue, expenses, assets, and liabilities.conf: high
explicitThe precise dollar figures shown in internal governance reports (e.g., 'Initiative A: $356,000') are governance artifacts invented to make complex work legible, and — outside of capitalization — these numbers never actually appear in the company's financial statements.conf: high
explicitEven strict external governance frameworks (e.g. Basel III for banks, government procurement rules) specify what must be controlled or achieved rather than dictating internal structure, leaving organizations far more latitude than is commonly assumed.conf: high
explicitAcross most governance frameworks, the intention, design, repeatability, and auditability of a process matter more than mechanical adherence to its specific procedural details.conf: high
explicitA company can follow every rule in its combined governance framework (procedural legitimacy) while the practice still harms investors, employees, customers, and taxpayers — procedural legitimacy and substantive legitimacy are categorically different tests, and satisfying one does not imply satisfying the other.conf: high
extendsTBM 414: Legibility and Legitimacy · p2 — Cutler's own earlier abstract distinction (legitimacy asks whether control is justified, not whether it's visible) is here operationalized into a concrete procedural-vs-substantive-legitimacy governance diagnosis.
explicitNone of the major governance guidance frameworks (OECD, CIPFA/IFAC, ERM, NIST, ISO 38500, ISO 9001) require projects, programs, stage gates, or initiative-organized portfolios; they require accountability, evidence, risk management, documented process, checkpoints, decision rights, and traceability — properties that durable units (capabilities, domains, journeys, product lines, platforms) can satisfy as well as, or better than, projects can.conf: high
extendsTBM 430: Incubate, Compound, Refinance, Liquidate · p6 — Both treat portfolio/investment health as a property of durable units and their flows over time, not of discrete time-boxed projects.
explicitCompanies default to project/program-based governance not because it is required but because of legacy frameworks from outsourcing/cost-center eras, governance models borrowed from unrelated domains (construction/manufacturing procurement), fear and inexperience about alternative accountability mechanisms, a false-precision bias toward allocated hours, and program/portfolio teams that only know how to target investment at projects.conf: high
explicitThe mismatch between governance structure and how product/platform work actually unfolds is not confined to legacy enterprises — self-described 'product operating model' companies show the same pathology through constantly shifting, ad hoc allocation taxonomies (BAU vs. strategic, Kano categories, CTO/CEO discretionary buckets) and artificial 'business unit' P&L constructs that misrepresent genuinely integrated, platform-like work.conf: high
explicitGovernance is fundamentally context-specific risk management, and when context (technology, architecture, team structure, uncertainty) changes, the governance model must eventually change too; a model built for a slow, predictable environment will not fit a fast, interdependent one.conf: high
explicitSoftware development sits near the dynamic end of the static-to-dynamic optimization spectrum (markets, customer behavior, dependencies, architecture, regulation, team skill, and the portfolio's own shape all keep changing), so treating products and platforms as static, optimizable 'projects' is a category error.conf: high
supportsDevOps Topologies · p2 — Batch sibling: both reject a single universal structural template in favor of context-contingent design — Cutler for governance units, Skelton for Dev/Ops team structure.
explicitPlatforms, shared services, and deep capabilities generate value on longer, less linear, more indirect timelines than work closer to customers; a governance framework biased toward short-term, visible outcomes will systematically starve them unless it explicitly protects a long-horizon investment lane.conf: high
supportsTBM 430: Incubate, Compound, Refinance, Liquidate · p4 — Both argue a platform's/deep-capability's worth must be judged by its longer-horizon, indirect value contribution rather than short-term, visible shipping output.
explicitcorroboratedTeam 'shapes' (in Team Topologies vocabulary: stream-aligned, platform, enabling, complicated-subsystem) are useful models, not permanent installations, and should be expected to evolve as products, architecture, and organizational needs change — governance should periodically re-check fit rather than install team types and forget them.conf: high
supportsTeam Topologies: Organizing Business and Technology Teams for Fast Flow · p19 — Cutler explicitly invokes Team Topologies vocabulary and echoes the book's own claim that no team-topology assignment is a final, static answer.
supports ←Scaling the Practice of Architecture, Conversationally · p14 — Both insist governance artifacts (principles, team shapes) must stay revisable rather than fixed installations — Harmel-Law's 'supersede via a new ADR' mechanism is a concrete implementation of the general claim that governance should periodically re-check fit.

Arguments

Organizations should rebuild governance around durable product/platform/capability units and dynamic-lifecycle principles rather than inherited project/program templates. strength: medium

Explicit premises:

Accounting standards don't require project/program structures (p1).
Major governance frameworks require properties (accountability, evidence, auditability) that durable units can satisfy as well as projects (p6).
Governance's job is context-specific risk management, and software's context is dynamic (p9, p10).

Implicit premises:

Organizations have, or can readily build, the measurement sophistication (KPIs, OKRs, causal theories, risk heatmaps) that durable-object governance requires to be genuinely auditable — a capability-building problem the piece mostly gestures at via named 'Example Mechanisms' rather than argues is tractable.
A principle-based governance regime is less prone to calcifying into procedural-legitimacy theater than a template-based one — but the piece never explains what structural feature of 'principles' makes them resistant to the same box-ticking fate as 'templates'.

Inferences:

The essay's own prescription — twelve principles, each paired with a named, repeatable 'Example Mechanism' (annual reviews, categorization exercises, heatmaps, dependency scoring) — is itself exactly the kind of templatable, checkbox-prone artifact the essay diagnoses as the procedural-legitimacy trap; nothing in the piece explains why these twelve mechanisms would resist the same fate as the project/program templates they replace.

Narratives

A company with a rigorous 'business case' ritual required before any work begins — forcing premature convergence on solutions, inflating estimates, producing a dozen teams claiming credit for the same unmovable metric, and triggering massive cross-team context switching — while technically following every rule in its governance framework.
→ Illustrates and motivates the procedural-vs-substantive-legitimacy distinction: full procedural compliance coexisting with real harm to investors, employees, and customers.
A VP of Product telling the author, 'If only investors understood what is happening here, they would flee en masse,' about a company whose governance is fully 'by the book' yet enormously wasteful.
→ Grounds the procedural-legitimacy critique in a specific, credible practitioner complaint rather than leaving it abstract.

Questions addressed

✅ Does GAAP/IFRS accounting actually require the detailed project/program coding and precise cost tracking many companies impose?
No — these are self-invented governance mechanisms, not accounting requirements; accounting cares only about revenue/expenses/assets/liabilities.
✅ Do major external governance frameworks require organizing investment around projects and programs?
No — surveyed frameworks (OECD, CIPFA/IFAC, ERM, NIST, ISO 38500, ISO 9001) require accountability, evidence, and auditability, which durable units (capabilities, platforms, domains) can satisfy without using project/program structures.
⭕ What prevents a 'governance by principle' approach from itself calcifying into the same procedural-legitimacy theater it criticizes in template-based governance?

Gaps

illogicalThe essay diagnoses procedural legitimacy (rule-following that is defensible on paper but substantively harmful) as the central governance failure mode, then prescribes exactly twelve named principles, each with a specific, named 'Example Mechanism' (annual reviews, categorization exercises, heatmaps, scoring rubrics). These mechanisms are themselves repeatable, checkbox-amenable rituals of precisely the kind the essay warns against — nothing in the piece explains what would stop 'governance by principle' from degenerating into a new, equally performative template once these twelve mechanisms are institutionalized.
Read next: extract-tbm-414-legibility-and-legitimacy, where Cutler develops the underlying legibility/legitimacy distinction more abstractly and flags that legibility-framed proposals often conceal a power shift — worth applying that lens back onto this essay's own twelve mechanisms.
incompleteWritten in November 2025, the essay treats team capacity, cognitive-load limits, talent fungibility, and the explore/expand/extract lifecycle as stable, human-team constraints on governance design, without addressing how AI coding agents are actively renegotiating exactly these constraints (team throughput no longer scaling purely with headcount in the old way, individual 'talent fungibility' changing when agents absorb some context-transfer cost, etc.).
Read next: This corpus's broader AI-era team-structure literature (e.g. extract-dora-ai-team-profiles-and-capabilities, extract-team-topologies) for how these same governance inputs are being revised.
incompleteThe essay asserts that durable units can be 'measured with KPIs, OKRs, service levels, risk signals, etc.' as if this measurement capability is simply available once an organization decides to adopt it, without engaging the extensive, separately-documented difficulty of building valid, non-gameable measurement for exactly these kinds of units (the same difficulty DORA/SPACE/DevX literature in this corpus wrestles with at length).
Read next: extract-cannot-measure-productivity and extract-dora-community-discussion-dx-core-4 (this batch) for the measurement-validity problem this essay assumes is solved.