LinkedIn Draft — Insight (2026-05-08)
One insight that changed how I design systems:
Feature flags are ops infrastructure, not a product team tool
Most platform teams treat feature flags as a product/A-B testing concern and miss the most operationally valuable use case: instant rollback for any backend change, without a redeployment. The teams with the lowest incident MTTR almost all have the same secret — they can disable any code path in 30 seconds.
Feature flag as ops tool:
New backend change ships ──▶ [flag: new_auth_flow = true]
│
Incident detected (T+12min)
│
[flag: new_auth_flow = false]
│
Recovery complete (T+13min)
vs. traditional rollback: Recovery complete (T+75min)
The non-obvious part:
→ A feature flag that can disable a code path in 30 seconds is worth more than any runbook during an active incident. It converts a deployment rollback — with its pipeline, merge, and propagation delays — into a config change. Most platform teams own the infra for this and never tell product teams it exists.
My rule:
→ Every significant backend change ships behind a flag for at least 2 weeks post-deploy. Flags are cheap. Incidents are not. Make flags a deployment requirement, not an option.
Worth reading:
▸ Martin Fowler — Feature Toggles pattern (martinfowler.com/articles/feature-toggles.html)
▸ LaunchDarkly / Unleash — flag lifecycle management and audit logging best practices
If this resonated, share it with one person on your team who'd benefit. That's how good thinking spreads.
Top comments (0)