Feature flags as micropolitics
Who decides what you see in a product, and how — a question of power, not configuration.
A feature flag looks like the most harmless thing in a codebase. A boolean, a switch, a line in a config. On — the user sees the new button. Off — they don't. Engineers treat flags as hygiene: they let you ship code without shipping functionality, kill a broken feature in seconds, roll a change out to one percent of the audience. All of this is true. But under the technical routine something larger is hiding.
01A decision dressed up as a setting
A flag is a decision about what to show, and to whom. Some users get one product, others get another, and the line between them is not drawn by chance but by someone's choice. That choice is not made in a meeting or in a public document. It is made in an interface for insiders — a control panel a handful of people can reach.
To call this a «setting» is to strip the decision of its weight. A setting sounds technical, neutral, reversible. But between «we decided to show this price only to this segment» and «we flipped a flag» there is no difference in substance — only in tone. The second sounds as though no one decided anything.
The smoother the tool, the more invisible the choice it encodes.
02The micropolitics of a rollout
A gradual rollout is usually explained through risk: ship to 1%, watch the metrics, and if all is well, go further. That is sensible. But notice what happens to the user. They become part of a sample without knowing it. Their experience is a measurement. Their behaviour on the new version is the data on which someone will decide whether everyone else sees it too.
This is not an abuse. It is normal engineering practice, and I have built the tooling that enables it. But it is worth naming plainly: a product is constantly running small, invisible experiments on its audience, and flag infrastructure is what makes those experiments cheap and routine.
03Power distributed across the code
The interesting part is where exactly this decision lives. Not in a manager's head, not in company strategy. It is distributed: partly in code, partly in configuration, partly in who can reach the panel, partly in an unspoken agreement about who may touch which flags. Power here is not concentrated — it is smeared across the infrastructure, which is precisely why it is hard to see.
When power looks like infrastructure, it stops being read as power. No one gives an order — the system is simply built this way. That is micropolitics: not loud decisions, but thousands of small, technically framed choices that together determine what the product is for each particular person.
04Why this matters to an engineer
You could say: so what, it's just work, flags are useful. Yes. I am not proposing we abandon them — that would be absurd. I am proposing something else: to see in a flag not only a technical abstraction but an imprint of a decision. Who made it. On what grounds. Who knows about it.
An engineer who holds this in mind designs differently. They ask who gets access to the panel, and why. They document not just what a flag does but why it exists. They notice when a «temporary» flag is in its second year and has quietly become a permanent, unexamined product policy.
This is the bridge between engineering and social theory. Not adding philosophy to code, but seeing that code already contains decisions about power and behaviour. The only question is whether we notice them.