I removed the requirement for a memorable payoff line from my Creating Taste writing instructions. I also removed the screenshot test: the idea that a piece was weaker if it lacked a line someone would want to capture and share.
Those techniques can help a piece of writing. Making them compulsory asks every article, explanation, and professional reply to perform the same trick. A useful answer to a colleague can be complete without auditioning for a motivational poster.
The harder decision was what to keep. I still wanted the writing checked for purpose, proof, distinctive judgment, and fidelity to what I had actually done. Simplifying the instructions meant separating those requirements from techniques that only sometimes improved the work.
That is the decision making trap I keep encountering in AI-enabled work: a sensible precaution becomes a permanent prerequisite, and nobody asks whether it still helps.
Key Takeaways
- A review requirement should protect a meaningful risk or inform a real decision.
- Even sensible precautions can become permanent delays when their purpose goes unquestioned.
- Keep necessary controls; narrow or remove checks that no longer help the decision.
A control should have a job
Dave Kellogg describes a related pattern in “Simplifiers Go Far, Complexifiers Get Stuck.” Progress slows while plausible-sounding prerequisites accumulate. His training example makes the problem concrete: before delaying a process change for a training program, consider whether a single page people can read in a few minutes would be enough.
My writing instructions had their own version of that problem. Shareability was useful to consider, but it had become an acceptance condition even when the job was to explain something clearly or participate in a professional conversation. The control was judging some work against the wrong purpose.
I changed the rule so usefulness, specificity, and authentic participation could satisfy it in those situations. Storytelling and a strong line remained available. Neither had to appear just to get the work through review.
The replacement instructions also retained firm boundaries: no invented personal experience, no unsupported results, and no obligatory call to action. I could remove the performance requirement without removing the obligation to tell the truth.
Check that the simplification actually reached the work
Editing the main instruction was only part of the job. The deployment review found a conflicting older method that still required the screenshot test. Leaving it active would have allowed the retired requirement to return through another reference.
That dependency was removed too. The deployment checks compared the installed files with the approved package, checked for the retired writing-system dependency, and confirmed that unrelated skills stayed unchanged. Those checks had a defined purpose: verify that the approved simplification was the version actually installed.
That is the outcome I can point to: revised instructions and checked dependencies. It is not a measured claim that my writing became better or faster. The exact fresh-session model regression suite was still unrun, so I could not treat the deployment checks as proof that every future session would behave correctly.
This is where simplification needs judgment. Removing a redundant writing rule was reasonable. Skipping the check for conflicting instructions would have left a known way for the change to fail.
Ask what would change the decision
Before adding another review, I want a specific answer to three questions:
- What could go wrong? Name the failure the control is meant to prevent.
- What would the result change? Explain what would make the work proceed, require correction, or wait.
- When is the check finished? State the evidence needed to close it.
A credible risk can justify a control before anyone experiences a failure. Access permissions, sensitive information, or a consequential financial claim may warrant review precisely because discovering the problem afterward would be costly. “We haven’t had a problem yet” is not a sufficient reason to remove the protection.
But a control that cannot change the decision deserves examination. If a narrower test resolves the risk, run that test. If required evidence or authority is missing, wait for it. If the work passes and nothing material remains unresolved, another round of subjective improvement needs a better reason than “we could make it stronger.”
Make the next step smaller, not less responsible
I have written about assigning AI systems clear responsibilities and refusing to build another marketing system just because I found a useful framework. This writing change was another application of the same judgment: improve the mechanism already doing the work before adding one.
Kellogg’s advice to answer an executive’s question directly applies here too. A leader should understand the complexity well enough to explain the decision, the remaining risk, and the next action without handing everyone the entire analysis.
For the next review you are asked to add, name what it protects and what evidence would close it. Keep the control that earns its place. Narrow or remove the rest, then let the completed work move.
