Question: Assuming that feature flag toggles are a good idea, and should be implemented into code that developers write. For example Etsy swear by them as a [major part of their culture](https://codeascraft.com/2011/02/04/how-does-etsy-manage-development-and-operations/).

**What is a good way to persuade (and enforce) developers to start using feature flag toggles?**

More information about feature flag toggles is explained in [Q: How to use feature flag toggles](https://devops.stackexchange.com/questions/162/how-to-use-feature-flag-toggles), [Q: What are feature flag toggles](https://devops.stackexchange.com/questions/344/what-is-a-feature-flag-toggle-and-when-to-use-them-or-not) and very extensively in Pete Hodgson's [article on the subject on Martin Fowler's blog](https://martinfowler.com/articles/feature-toggles.html).

Answer: 
A successful high-velocity development environment typically relies on a pretty strict automated system involving quality verifications with detection and rejection of faulty changes causing regressions.

Feature toggles offer the ability to commit even work-in-progress, untested changes without getting rejected for causing regressions in the integration branch. Which constitues a very good **incentive** to introduce the feature toggles very early in the life of the feature.

One of the disadvantages of deviating from true CI and moving feature development on feature branches is the lack of such incentive. Adding the feature toggle later on, when merging the feature branch into the integration branch is typically more difficult, like any late integration.
The rationale to have feature toggles is not something for developers to decide. This is something for product owners to care. Developers enable this change in the most sustainable and safe manner. I critique this very question.