> That does not sound much like a “weekly release” though I respectfully disagree, because I'd say that a "release" ought to be defined from the viewpoint of a

> That does not sound much like a “weekly release” though I respectfully disagree, because I'd say that a "release" ought to be defined from the viewpoint of a given individual user. From that person's perspective, they are indeed seeing things change only weekly, and the details of how that's done (e.g., feature flags vs giant deployments) are mostly irrelevant to them. > It’s not insurmountable. But it’s not trivial in my experience. You are right. Honestly, I'm so used to having to sell the idea that I just reflexively wrote it that way. Thank you for listing out the different pieces. You're absolutely right there is a lot of extra "essential complexity" that gets added in. Even if the "actual" coding work is "just a few" extra if-clauses and tests (which is how I'd sell it ;), everyone has to hold a lot more in their heads. Personally, though, I would still insist that it's way better than the essential complexity that gets added everywhere by coupling "releases" with "deployments." In my experience, once an org lets product-release-tempo dictate engineering-velocity-tempo, the bureaucrats essentially have a chokehold on all engineering decisions. The organization slowly grinds to a halt; high-value customers start getting picked off by nimble, faster-moving startups; and the circle of life continues. Feature flags are IMHO a key technique for a startup-that's-getting-bigger to hold off this particular mechanism of decline. Non-technical stakeholders at all levels can be easily waved off with a simple remark of, "Well, we'll feature-flag it." And engineers can stay much more empowered, even as the company grows much bigger.