Decision and Operations 6

Feature flags create controlled variability. Governance is what prevents that variability from becoming permanent confusion.

Classify flags at creation

At minimum, distinguish release, operational, experiment, entitlement and dynamic configuration flags. Their expected lifetimes and permissions are different.

Use naming that communicates intent

A useful name should describe the capability rather than the person or sprint that created it.

good: checkout-address-validation-v2
weak: jacob-test-flag
weak: sprint42-newthing

Teams may also encode domain or service ownership in metadata rather than forcing every fact into the key.

Require ownership and purpose

A flag record should answer:

  • who owns it?
  • what behavior does it control?
  • what type of flag is it?
  • which environments may use it?
  • when should it be reviewed or removed?

Temporary flags need an expiry expectation

A release flag should not quietly become permanent configuration. Teams can assign a target removal date or automatically identify flags that have remained fully rolled out for too long.

Production permissions should match risk

Changing a button color experiment and disabling payment validation do not have the same blast radius. Use roles, approvals and environment permissions that reflect the risk of the controlled behavior.

Emergency controls need a separate rule

An operational kill switch may need to bypass normal waiting periods during an incident. That exception should be explicit, limited to authorized responders, audited, and reviewed afterward.

Auditability is part of debugging

Audit history is not only for compliance. During an incident, engineers need to answer: what flag changed, who changed it, in which environment, and when?

Make cleanup part of delivery

create release flag
      ↓
ship feature
      ↓
reach 100%
      ↓
remove old implementation
      ↓
remove flag
      ↓
close cleanup work

If cleanup is left to memory, it will lose against new feature work. Put it in the delivery definition of done or create automated stale flag workflows.

Govern the control plane, not every if statement centrally

An enterprise architecture team should define standards and guardrails without becoming the approval bottleneck for ordinary team owned flags. Centralize the rules that protect the enterprise; decentralize routine ownership to the teams closest to the software.

Feature Flags series

← Operating Feature Flags at Scale   Designing an Enterprise Feature Management Architecture →