Feature flags as micropolitics
Who decides what you see in a product, and why a switch in a config hides a question of power.
A feature flag looks like the most harmless thing in a codebase. A boolean, a switch, a line in a config. On, and the user sees the new button. Off, and they don't. Engineers treat flags as hygiene: you can ship code without shipping the functionality, kill a broken feature in seconds, show a change to one percent of the audience, roll the whole thing back with one click at three in the morning. All of it is true, and I have spent seven years living inside that truth. But the harmless line in a config has a second life, the kind that doesn't usually come up at code review.
A decision dressed up as a setting
A flag decides what to show and to whom. Some users get one product, others get another, and the border between them runs along someone's choice. That choice is rarely made in a meeting or in a public document. More often it's made in a control panel that a few people can reach, and it takes about five seconds.
For years I worked with Unleash, a feature-flag platform we developed and extended to fit our own processes. The panel there is honest and easy to use: a list of flags, toggles, rollout percentages, strategies by segment. You go in, drag the slider from 5 to 25 percent, hit save. No drama. And the smoothness is the whole point of it: the interface is built so the decision feels like adjusting screen brightness, though in its consequences it sits closer to an editorial one, who sees the new price and who sees the old.
Calling it a "setting" takes the weight off the decision. The word sounds neutral and reversible. Between "we decided to show this price only to this segment" and "we set a flag" the only difference is tone. The second one sounds as if no one decided anything, as if it just fell into place by itself.
The micropolitics of a rollout
A gradual rollout is usually justified through risk: ship to one percent, watch the metrics, and if all is well, keep going. Reasonable enough. But look at what happens to the person on the other side of the screen. They land in the sample without knowing it. Their experience of the product becomes a measurement. Their behaviour on the new version is the data that later decides whether everyone else gets to see it.
There's no ill intent here. It's normal engineering practice, and I'll say it again: I built the tools that make it possible, and I think they're useful. But it's worth naming things directly. A product is constantly running small, unnoticed experiments on its audience, and flag infrastructure makes them so cheap and routine that people stop thinking of them as experiments at all.
I remember a night incident. A new feature rolled out to 10 percent, the payment metric for that segment sagging, the on-call engineer (that was me) staring at a graph that diverged from the control group. Five minutes to diagnose, one toggle to zero, payments recovered. As engineering, it was clean. But in hindsight I think about the people who made up those ten percent: for an hour or two the product simply worked worse for them, no one asked them about it, and in the report they stayed a single line, "rollout reverted, impact limited."
The flag that's in its second year
The most honest portrait of power in code is not the dramatic incident, it's the forgotten flag. We had one turned on at 100 percent, set as temporary for the length of a migration. The migration ended, the flag stayed. A year went by. It sat in the panel, green, untouched, and formally it still "governed" behaviour, though not a living soul remembered what would happen if you switched it off.
When we finally got to the cleanup, the funny part came out: the flag was hiding a whole branch of commission-calculation logic that someone had "temporarily" covered up once and then simply got used to. Deleting it was frightening, something might break. Leaving it meant carrying a decision in the codebase that no one had consciously made in a year. A temporary flag had quietly become permanent product policy, only policy with no author: nobody approved it, it just stopped being turned off.
That is the part that gets to me. An order can be challenged, an order has someone who gave it. A stuck flag has no one to answer for it: there's a commit from two years back and a person who left the company long ago.
Power spread across the code
Where does the decision to show one user one thing and another user something else actually live? Not in a manager's head, not in the strategy on the slides. It's spread out: part in code, part in configuration, part in access rights to the panel, part in an unspoken deal about who can touch which flags in prod without asking. Power is spread across the infrastructure, and that's what makes it hard to see.
Once at a code review I caught myself: the argument had drifted from the code to the access list. A colleague was creating a new flag with the right to toggle it in prod for the whole product team, some twenty people. Technically flawless. I asked to narrow it to three, and we bickered for half an hour, because my request looked like bureaucracy and like distrust of the team. I just didn't want the decision about what users see to be something any one of twenty people could make alone, leaving no trace. We settled on an audit: you can toggle it, but every toggle gets written to a log with a name. A mediocre compromise, if I'm honest. Nobody reads the log until an incident happens.
When power looks like infrastructure, people stop noticing it's there at all. No one issues instructions, the system is just built that way. It's out of thousands of small, technically framed choices that the product takes the shape it does for one specific person.
Why keep this in mind
It's easy to object here: look, it's just work, flags are useful, you've said it a hundred times yourself, don't invent philosophy out of nothing. The objection is fair, and I half agree with it. Giving up flags would be absurd, and I'd be the first to refuse. But giving them up isn't what I'm suggesting. I'm suggesting a habit of seeing in a flag also an imprint of a decision: who made it and on what grounds.
An engineer who keeps this in mind designs a little differently. He asks who gets access to the panel and why. In the flag's description he leaves the reason: what it was created for and when it's meant to come out. He notices the green toggle that's been hanging there for a second year, and doesn't walk past.
Does it actually help? I'm not sure. I still create flags, still move sliders, and half of my own flags are documented any old way. One small thing has changed: dragging the slider from 5 to 25, I stop for a second to think whose experience I'm changing right now and whether anyone ever asked those people. Usually no one did. I move the slider anyway. But in that second the setting briefly becomes a decision again, and I have nothing yet to put in place of that second.