Taste begins with sight.
Not eyesight. Recognition.
A senior engineer sees a shortcut and knows it will become painful. A strong product leader sees a feature request and knows the problem is actually onboarding. A good editor sees a polished paragraph and knows it is avoiding the point. A skilled manager hears a status update and knows ownership is unclear. A sharp operator watches a vendor demo and knows the integration story is too convenient.
From the outside, this looks like intuition. Inside, it is trained perception.
People with taste have seen enough examples, failures, consequences, and recoveries that patterns compress. They do not need to consciously replay every case. They can feel the shape of the problem because they have seen the aftermath before.
That does not make taste mystical. It makes it trainable.
The first way to train taste is to study exemplars. Real ones. Not principles in the abstract. If you want better product taste, collect flows that solve the user’s anxiety instead of merely exposing controls. If you want better writing taste, collect memos that name tradeoffs, evidence, and decisions cleanly. If you want better technical taste, study architectures that aged well and ask why. If you want better management taste, study updates, reviews, and planning docs that made ownership unmistakable.
Exemplars give people a target. They answer the question, “What does good look like here?”
But exemplars are not enough. Teams also need anti-examples.
Anti-examples are the plausible failures: the work that looks acceptable until someone with better judgment points out the problem. The landing page that is polished but generic. The AI summary that is fluent but unsupported. The candidate who interviews well but shows no evidence of operating discipline. The feature that satisfies the request but increases support burden. The strategy deck that sounds confident but makes no real choices.
Anti-examples teach the boundary. They show the difference between “fine” and “not good enough.”
Most organizations do not keep these examples. They fix the work, ship the better version, and lose the learning artifact. That is waste. The rejected draft is often more educational than the final one because it reveals what the organization refuses to accept.
A strong team keeps a small museum of judgment.
Here is the weak customer email and the better one. Here is the product concept we killed and why. Here is the AI output that looked good but failed source review. Here is the hiring scorecard that protected us from charisma bias. Here is the technical decision that seemed slower but prevented ownership confusion. Here is the strategy memo before and after it named the actual tradeoff. Here is the management update that said "on track" while hiding a blocked dependency, beside the revised version that named the owner, date risk, and escalation path. Here is the design review where a beautiful empty state was rejected because it solved brand anxiety instead of user anxiety.
The point is not nostalgia. It is calibration.
The second way to train taste is to study aftermath. Taste improves when people connect decisions to consequences. What happened after launch? Did customers understand? Did support volume drop or increase? Did the code become easier to change? Did the positioning attract the right buyer? Did the hire thrive in the actual role? Did the AI workflow save time after review cost, or only during generation?
Postmortems are taste training when they go beyond process. A normal postmortem asks what broke. A stronger postmortem asks what signals were visible before it broke. What did good judgment miss? What did weak judgment ignore? Which concern was dismissed as taste but turned out to be real? Which objection was just preference?
That is where consequence literacy develops.
The third way is critique with reasons. Critique that stays at “better” or “worse” teaches dependence. Critique that names mechanisms teaches sight.
Do not say only, “This feels generic.” Say: “The copy could be used by any company in the category. It does not name the buyer’s real risk, the moment of value, or the reason to believe.”
Do not say only, “This spec is weak.” Say: “It names the happy path but not ownership, failure behavior, rollback, support impact, or the metric that tells us whether it worked.”
Do not say only, “This AI answer is not good.” Say: “It is fluent, but it does not cite the source for the decision-critical claim, and it collapses two different customer segments into one recommendation.”
The sentence after the judgment is where teaching happens.
The fourth way is constraint. Taste without constraint becomes fantasy. Anyone can imagine a more polished version if time, money, talent, and patience are unlimited. Operators need taste that works inside reality.
The question is not “Can this be better?” Almost everything can be better. The question is “What kind of better matters here?”
A prototype needs learning speed, not final polish. A customer trust issue needs precision, not cleverness. A payment flow needs reliability, not novelty. An internal brainstorm needs range, not consensus language. A performance review needs evidence, not elegance. A strategic decision needs tradeoffs, not theater.
Constraint teaches proportion. It helps people learn which quality attributes are load-bearing.
The fifth way is repetition with feedback. Taste is not built by reading one essay about taste. It is built through loops: attempt, compare, critique, revise, ship, observe, adjust. The loop has to be tight enough that people can connect correction to consequence.
This is why apprenticeship still matters, especially in AI-assisted work. If junior people only receive finished machine output and approval decisions, they may produce more while seeing less. They need reps in reviewing, rejecting, comparing, explaining, and improving. They need to learn why a plausible answer is not good enough.
Leaders often complain that teams “do not have taste.” Sometimes that is true. More often, the organization has not built the conditions for taste to develop. It has no examples, no anti-examples, no critique language, no aftermath review, no calibration rituals, and no visible standards.
Then everyone acts surprised when quality depends on the senior person in the room.
The practical move is simple: make taste observable.
Pick one domain: writing, product, design, technical decisions, hiring, AI outputs, customer communication. Collect five excellent examples. Collect five plausible failures. Write the reasons. Review new work against them. After the work hits reality, update the examples.
This is not bureaucracy. It is how teams learn to see.
Taste is not a gift handed to a few people. It is perception trained by reality. The sooner a company treats it that way, the sooner quality stops being a private talent and becomes an organizational capability.
