Conceptadvanced

Governance from the Setter's Perspective

Overview

The previous level describes how governance operates. This document covers whoever creates it — and the difference is large, because the creator has a responsibility the operator does not:

operating   making the mechanism work
creating    deciding whether it should exist, and for how long

Every organization has a process for adding mechanisms: an incident happens, a control is created. Almost none has a process for removing them — and that asymmetry is the cause of all bureaucratic accumulation.

adding     has an owner, urgency and an incident to justify it
removing   has no owner, is politically risky, and the
           benefit is diffuse

Whoever establishes governance has to design the second half too.

Problem

The typical mechanism is born like this:

incident   a service went to production without a security review
response   every release now requires security approval
result     three years later, 400 approvals a year, of which
           two found something

The original response was proportional to the incident. It stopped being proportional when the organization built automated security checking and nobody revisited the manual mechanism.

And there is a second pattern: the mechanism created with no measure. It cannot be assessed, because what it should produce was never defined — and without that, the discussion about keeping it is a discussion about opinion.

Core Concepts

Every mechanism is born with four fields

the risk it addresses          specific, not a category
how the effect will be measured  how many times it caught something
the estimated cost             average delay × volume
the owner                      a role, not an area
the expiry date                24 months at most

The last two are what almost every existing mechanism lacks. With no owner, it isn't adjusted; with no expiry, it is permanent by omission.

See measuring governance.

Pick the earliest viable point of intervention

Before creating a human mechanism, the question:

"can this be prevented in the environment or in the template,
 instead of being verified by someone?"

in the environment   the wrong path doesn't exist
in the template      it is born correct
in the pipeline      it fails automatically
in a review          someone notices
in a committee       someone notices weeks later

A human mechanism created when an automated one was viable costs forever. See governance basics.

An annual removal target

The structural intervention that solves accumulation:

"we remove at least one mechanism a year"

That gives the act of removing an owner, which was what was missing. And it forces a review of the whole set, because choosing which one to remove requires looking at all of them.

An organization that has never removed a mechanism has, with high probability, more mechanisms than it needs — and the diagnosis holds regardless of which one you examine first.

Suspending beats arguing

arguing about whether a mechanism is necessary   indefinite arguments
suspending it for a quarter                      evidence in three months

Temporary suspension is the most effective instrument and the hardest to get authorization to use. It produces evidence no analysis produces, and it is applicable to everything except regulatory and critical-security controls.

Proportionality to risk, always

a regulated critical system    a heavy mechanism is justified
an internal tool used
  occasionally                 the same mechanism is waste

Applying governance uniformly is the error that consumes the organization's patience on irrelevant cases — and the patience runs out precisely when an important case comes along.

Scaling by criticality requires a classification that should already exist for other reasons: disaster recovery, incident response, access control.

Whoever creates it has to operate it for a while

An uncommon and revealing practice: whoever proposes a mechanism operates it for the first few months.

That produces two things. The mechanism's cost becomes visible to whoever created it, and not only to whoever suffers it. And the design improves fast, because whoever feels the friction has both the incentive and the authority to adjust it.

The practice also corrects a common asymmetry: mechanisms tend to be proposed by whoever is accountable for a risk and operated by whoever is accountable for delivery, which separates whoever decides the cost from whoever pays it. Joining the two roles for a few months is the cheapest intervention against disproportionate proposals, and it requires no process at all — just the rule.

Good governance is invisible

a visible mechanism     someone has to do something extra
an invisible mechanism  the easy path is already the correct one

The goal of whoever establishes governance should be to make the mechanisms unnecessary — moving what they verify into the platform, the template and the pipeline.

A governance group whose success is measured by the number of mechanisms operated has the incentive inverted. See platform engineering.

Mental Model

Every mechanism is born with an owner, a measure and an expiry. And the organization needs a removal target, because adding has an owner and removing doesn't.

When to Use

When creating any governance mechanism.
In the periodic review of the whole set.
Before responding to an incident with a new control.

When Not to Use

With no owner, measure and expiry.

When the automated point of intervention was viable.

Uniformly, without scaling by criticality.

With no removal process.

Creating a mechanism as a reflex response to an incident.

Alternatives

A platform — moving the property into the paved path, eliminating the mechanism.
A fitness function — automated rather than human verification. See fitness functions.
Registration without approval — for low risks, visibility is enough.
Nothing — formally accepting the risk is a legitimate answer. See risk management.

Trade-offs

A formal mechanism	A platform
Fast to institute	Expensive to build
Permanent friction cost	One-off cost
Circumventable	Invisible and effective

A short expiry	A long one
Frequent review	Less overhead
Cost of renewing	Permanence by omission

Failure Modes

Accumulation. Adding has an owner, removing doesn't.

A mechanism with no measure. Impossible to assess.

No expiry. Permanent by omission.

Uniform. Consumes patience on irrelevant cases.

Human where automated was viable. Perpetual cost.

Success measured by number of mechanisms. Inverted incentive.

Common Mistakes

Responding to an incident with a control without assessing the point of intervention.

Not defining how the effect will be measured.

Not assigning an owner as a role.

Never removing anything.

Not scaling by criticality.

Real-World Example

A logistics company with 160 engineers suffered a credential leak: an access key to an object store was committed to a public repository by mistake, and stayed exposed for nine days.

The immediate institutional response was the expected one — create a security review committee for every release. Architecture leadership asked for two weeks before instituting it, to design the mechanism with the four fields.

The exercise changed the response:

risk addressed      a credential exposed in a repository
                    — specific, not "code security"
effect measured as  credentials detected before reaching the
                    remote repository
estimated cost      committee: ~3 days of delay × 340 releases/year
                    ≈ 4 person-years of calendar time
                    automated checking: ~0
earliest viable point of intervention: in the version control client,
                    before the push

The committee was never created. In its place: a local check at push time, a check in the pipeline as a safety net, and automated credential rotation with a short lifetime — so that an exposed key expires before it is useful.

The human mechanism that remained was small and specific: a mandatory security review only for services exposing a new public surface, roughly 12 a year instead of 340.

Owner, expiry and measure were defined before anything was turned on. Owner: the platform maintainer role. Expiry: 24 months. Measure: credentials blocked before the push.

Over the following 24 months:

credentials blocked before the push          41
credentials that reached the repository       0
delay added to the release process            0
human security reviews performed             23 (from the forecast 12/year
                                             plus exceptions)

At renewal, at 24 months, the owner presented the numbers and the mechanism was kept — with the scope of the human reviews widened to include integrations with external partners, which had shown up as a gap.

The lesson that stuck: the question "what is the earliest viable point of intervention?" turned a proposal costing four person-years of annual delay into a zero-cost mechanism. And it cost two weeks of waiting — which was the politically hard part, because right after an incident the pressure is to act, not to design.

Practical Exercise

Ask, in your organization: what was the last governance mechanism removed, and when?

If nobody can answer, the set has only grown — and the diagnosis holds regardless of which mechanism you examine first.

Interview Questions

Why does adding mechanisms have an owner and removing them doesn't?
Why does suspending temporarily produce more than arguing?
Why should whoever proposes a mechanism operate it?

Overview​

Problem​

Core Concepts​

Every mechanism is born with four fields​

Pick the earliest viable point of intervention​

An annual removal target​

Suspending beats arguing​

Proportionality to risk, always​

Whoever creates it has to operate it for a while​

Good governance is invisible​

Mental Model​

When to Use​

When Not to Use​

Alternatives​

Trade-offs​

Failure Modes​

Common Mistakes​

Real-World Example​

Related Concepts​

Practical Exercise​

Interview Questions​

Further Reading​