Exec Feedback Is a Symptom, Not a Spec

I once spent three rounds of review trying to get a senior leader to sign off on a template system — a set of documents my team would use to run spec-driven work. Each round, the feedback was some version of “this still feels off.” Never a crisp requirement. Never “change X to Y.” Just a reaction.

The tempting move is to treat that as a guessing game: keep proposing variations until one stops drawing a frown. That way lies infinite rounds. The better move is to treat the reaction as a symptom and go find what it’s pointing at.

Reaction, not requirement

Senior feedback is very often a felt sense that something’s wrong, not a specification for how to fix it. That’s not a failure on the leader’s part — noticing that something’s off is a different, faster skill than articulating why. But it does relocate the work. The job isn’t to extract a spec they don’t have. It’s to convert their reaction into a concrete, defensible decision they can recognize as right.

So after each round I stopped asking “what do you want changed?” and instead synthesized the reaction into a specific structural move, then brought that back. Round by round, the system got smaller. I dropped a framing that was creating confusion. I treated the whole set of documents as a single approval unit instead of a pile of separate ones. And ultimately I consolidated four templates into three — folding two overlapping specs into a single document.

Naming was half the problem

One of the most useful changes wasn’t structural at all. The word “spec” was doing too much work — it appeared across five different artifacts, meaning something slightly different each time. No amount of restructuring could fix the confusion, because the confusion was lexical. Renaming one central document so an outsider could tell it apart from the others did more for clarity than any content edit. When a term is overloaded, people feel the friction long before they can name it — and “this feels off” is exactly what that friction sounds like.

The pattern

Two things I now reach for whenever feedback is vague and senior.

First: when you can’t get a requirement, propose a decision. Turn the reaction into a specific, defensible choice and let them react to that. A concrete option is far easier to confirm or reject than an open question is to answer.

Second: the winning move is usually to cut, not add. Every round of this shrank the system — fewer templates, fewer headings, clearer names — and every round it got better. Vague discomfort with something complex is very often complexity itself asking to be reduced. When a leader says “this feels off,” simplification is a shockingly good first guess.