Configurability as deferred decision-making, seen up close in media production

We spent six weeks inside a post-production house before we proposed anything. The brief said the problem was reporting. It wasn't reporting. Two days of watching producers work through north of 600 deliverables a month made that obvious, and dashboards had nothing to do with it.

Every setting is a decision someone refused to make, handed to a user who has less context than you do. Some of those handoffs are right. Most are a way of avoiding an uncomfortable conversation, and they're paid for later by whoever has to support all the combinations.

WHAT A SETTING REALLY COSTS

A boolean flag doubles the number of systems you support. Two flags give you four. Nobody plans for this, because each flag arrives on its own, attached to a reasonable request, and the cost only appears in aggregate when a bug report says "it doesn't work" and you need six questions to find out which product they're describing.

The support cost is the obvious one. The subtler cost is that configuration is where domain knowledge goes to die. Once behaviour is a setting, the reason behind it stops being written down anywhere, and in two years nobody can tell you why the value is what it is or whether it's safe to change.

WHEN IT IS THE RIGHT CALL

Sometimes the variation is real and permanent: tax rules that genuinely differ by jurisdiction, thresholds a regulator sets, anything a client can be legitimately audited on. Those belong in configuration, ideally with the reason attached and a name that says which law it serves.

The distinction we use is whether the variation is in the world or in the argument. Variation in the world deserves a setting. Variation in the meeting deserves a decision.

The clearest thing we saw was how producers handled a contested delivery package. On paper it's one step. In practice it's five, three of them over the phone, none of them written down. Which is why nobody could ever explain on-time delivery to their director.

DECIDING IN PUBLIC

The alternative to a flag is a decision with a name on it. Write down what you chose, who chose it, and what you'd need to see to change it. That's three sentences and it does more for the next team than a settings page ever will.

It also makes the reversal cheap in the way that matters. Nobody's afraid to change a documented decision. Everyone's afraid to change an undocumented default that eleven clients might depend on.

Here it showed up as a queue nobody owned. North of 600 deliverables a month went through it, and producers had learned to check it twice a day because the alternative was a master was published with the wrong audio mix attached. A better queue wasn't the answer. Making ownership a property of the delivery package was.

WHERE IT GOES WRONG

• A settings page that nobody can explain, where three values are load-bearing and the rest are noise.
• Bug reports that can't be reproduced until you've established which of sixty-four variants the reporter is running.
• Config that encodes a decision but not the reason, so nobody dares touch it after the author leaves.
• Shipping a flag to end a design argument, then discovering both branches are now in production.

Variation in the world gets a setting. Variation in the meeting gets a decision.

WHAT WE TOOK AWAY

The work shipped and on-time delivery moved, but the thing we're proudest of is smaller than the system: producers stopped keeping a private spreadsheet. That's usually the honest signal that the model finally matches the job.