Feature Flag

A feature flag decouples deploying from releasing: new code ships to production switched off, and is turned on — for everyone, for a slice, for named accounts — when the business says so. Engineering's answer to 'the code is ready but the timing isn't', and quietly one of the most commercially useful ideas in modern delivery.

What It Is

A feature flag (or feature toggle) is a runtime switch controlling whether code paths execute: the code is deployed everywhere but dormant until the flag is enabled, and can be disabled without a redeployment. Flags serve several masters: release control (ship dark, enable when ready), canary and A/B exposure (enable for 5% of users and measure), operational kill switches (disable a misbehaving feature instantly, without rolling back the release), and entitlement (premium features enabled per customer tier). The cost discipline: every flag is a branch in the code that must eventually be removed, or the codebase ossifies into an untestable combinatorial maze.

Why It Matters to You

For executives, feature flags change the release conversation from a technology event into a business decision. Deployment — getting code into production — can proceed continuously and safely while release — exposing it to users — happens on the business's clock: after marketing is ready, after training, after legal sign-off, on the launch date. The kill switch also buys incident resilience that rollback cannot: a faulty feature switched off in seconds, no redeploy. The cautions are flag debt (stale flags making the system untestable) and data integrity (flags hiding half-finished schema changes), which mature teams manage with expiry dates and flag hygiene reviews.

When You'll Meet It

In launch planning and programme governance — especially where commercial timing must control technical exposure. If timing matters to a release, ask for it to be flagged rather than scheduled.