Field Notes · august 2026
No Accounting for Taste
Taste and the numbers aren't supposed to share a room. One patient read, pointed at both — and why sameness earns less, not more.
Two things aren't supposed to share a room. Taste — the judgment about whether a piece of work is any good — which no formula has ever captured. And the numbers a business runs on: margin, return, the cost of a thing weighed against what it brings back. The reflex is to pick a side. Creative people learn to distrust the spreadsheet. Operators learn to distrust the vibe. Everyone I've watched do this work well refused the choice and built something that could hold both instead.
You start by reading taste rather than imposing it. A body of work is already telling you what it is — its visual language, the strains running through it, where it's sure of itself and where it isn't. Reading that is closer to investigation than decoration. I've sat with work that looked simple on the surface, the kind of thing easy to dismiss in a glance, and found a layer down that the simplicity was the point — a specific process, an unusual use of a tool, a discipline the surface was quietly carrying. The work tells you what it is. The job is to listen well enough to hear it, and to believe what it says.
That same read — patient, evidence-first, willing to be surprised — is what you bring to margin and market. It's one read, pointed at two kinds of material.
Here is where the tension actually lives. A client wants to feel that what they're getting is theirs: chosen for them, right for their space, unlike anyone else's. That desire is real even when the underlying thing is reproducible at scale. The business needs the opposite — predictability, a benchmark it can plan against, some assurance the next bet returns like the last one did. Those pull against each other, and the obvious move is to resolve the pull: standardize toward what's worked, invest more in the safe thing, formularize the collection.
It's the wrong move, and not for the reason creative people usually give. A homogeneous collection doesn't just feel stale, it earns less. Sameness has diminishing returns. The formula that promised predictability quietly stops paying, because the thing that made the work worth buying was its difference, and you optimized the difference out. Visual diversity isn't a tax you pay to honor taste at the expense of the numbers; it's what protects them. The rigid version loses on both counts.
So how do you hold both without one of them winning? You stop building programs and start building systems — and the difference is not a matter of degree.
A program optimizes toward one target. It does the same thing for the same reason every time, which is its strength, right up until it meets a case the target can't account for. Then the program is simply wrong, and it breaks at the edge. A system is different in kind. It does different things for different reasons, because it reads each situation and routes the call rather than pre-deciding it.
An example. Every so often the margin on a project says pass — the return isn't there. And you take it anyway, because the read tells you this particular one opens a door: it puts you in a room you couldn't otherwise enter, or earns a trust that cascades into higher-margin work later. That isn't a rule you could write down. "Take low-margin work" is a bad rule; so is "never take it." The call depends on what the situation is telling you about its second- and third-order consequences, and the only thing that can make it is a system built to read and route, not a program built to protect a number.
This is the part people get backwards: a system like that isn't looser than a program. It's built to a harder specification. A program only has to hit its target. A system has to hold a tension and keep reading — which is more structure, not less, just structure pointed at a relationship instead of a rule. What no one can hand you is the read itself — and the situation never stops talking.
If you're building something — a function, a team, a product — this is the part I'd pass along. You start by stating the utility plainly: what is this for, and does everyone building it know it. You build the thing to generate that value. Then the hard part — getting out of your own way enough to read what it actually does. Not what you proposed it would do — what it's doing. A system that can only produce what you projected is a program, and the value you didn't plan for is usually the point; it's the reason you left the gap open instead of closing it. When the thing isn't behaving the way you drew it up, you're slow to call it broken. You meet it where it is. You read it the way you'd read the work, or the market, or the client — as something with its own information to give you, that you'll miss entirely if you've already decided what you were going to find.
The taste and the numbers never fully reconcile. That isn't the flaw in the work. It's why the work stays alive