Effective business communication is a control on output quality, not a matter of style. When an instruction can be read two ways, it will be read two ways, and the difference shows up in the work that comes back. Writing that removes the second reading also removes the second version of the deliverable.
Ambiguity Does Not Stay Where It Started
A vague request feels free at the moment it is sent. The sender is satisfied, the recipient nods, and the exchange closes without anyone objecting to anything.
The bill arrives later and lands somewhere other than the conversation that created it. A designer returns something the requester never pictured. An analyst builds a report answering a question nobody asked. A supplier ships to a tolerance that was implied rather than stated.
Each of those outcomes is attributed to the person who produced the work. The producer is told to pay closer attention next time, and the instruction that caused the divergence goes unexamined.
The misattribution is durable because the instruction feels obvious to the person who wrote it. Intent is fully present in the mind of the author, which makes its absence on the page very hard to notice.
Reviewing returned deliverables against the requests that produced them settles the question quickly. Where several capable people produced different things from identical wording, the wording is the variable.
That test is available to any manager and is almost never run. Output gets inspected constantly while the instruction that generated it gets inspected almost never.
Speed is the usual defence of the vague request. Writing less feels faster, and it is faster for exactly one person in the exchange.
The recipient absorbs the entire difference without ever seeing the trade. Time that the sender saved by not deciding reappears as time the recipient spends inferring, and inference is far slower than reading.
Where Variance Enters a Written Request
Divergence enters written instruction at a small number of predictable points. Those points are few enough that any sender can check all of them before pressing send.
The first point of entry is the verb chosen by the sender. Words such as review, update, look into and handle describe a direction of travel rather than a finished state. Two competent people will land in entirely different places from the same verb.
The second point is the object of the sentence. A request to update the pricing page does not say whether the numbers, the layout, the wording or all three are in scope. The recipient guesses, and the guess stays invisible until delivery.
The third point is the standard being applied. Most requests never state what an acceptable result looks like, so the producer supplies a standard drawn from previous employers and previous managers. Those standards differ, and nobody discovers the mismatch until the work is inspected.
The fourth point is the date, which is usually stated and rarely specified. A day without a time and without a definition of finished still leaves room for argument on the day itself.
The fifth point is the decision right held by the recipient. Requests seldom say whether the recipient may make judgment calls inside the task or must return with questions first. Both behaviours are defensible, and choosing the wrong one wastes a full cycle.
Each of these points can be closed with a single clause. None of them requires a longer message, only a decision made before writing rather than after reading.
Recurring requests reward the effort more than any other kind. A standing instruction that is specified once removes the same ambiguity every week for as long as the task exists.
One-off requests still deserve the discipline, though the return is smaller. The judgement worth making is whether a wrong result would be expensive to discover late.
Describing a Situation Is Not Instructing
A great deal of workplace writing describes a state of affairs and then stops. The author assumes the required action follows obviously from the facts presented.
The required action almost never follows as obviously as the author assumes. A description invites interpretation, and interpretation is precisely the step that introduces divergence between what was wanted and what appears.
The gap between the two forms is small on the page and large in consequence. Saying that the reconciliation is behind is a description. Saying that the reconciliation should be completed through the end of last month by Thursday, with unmatched items flagged, is an instruction.
Instruction requires the author to decide something before the writing begins. That single requirement explains why description remains so much more common than instruction inside working organisations.
Describing defers the decision to the reader while appearing to have communicated. The author feels finished, the reader feels informed, and the deciding has quietly moved to whoever is least equipped to do it.
Seniority makes the habit worse rather than better. The more context a person holds, the more of the reasoning they leave unstated, because it feels redundant to them.
Recipients then receive the conclusion without the constraint that produced it. They comply with the words and violate the intention, which is the most expensive form of obedience available.
The habit deserves naming because it hides inside articulate, well-structured prose. Fluency is not specificity, and the most eloquent messages inside a business are often the least actionable. Much general guidance on how businesses should handle written instruction treats clarity as concision, when the harder discipline is deciding what the reader must actually do.
Writing Treated as a Standard Rather Than a Talent
Most businesses treat writing as an individual attribute. Some managers write well, others do not, and the difference is accepted as a matter of personality.
Treating it as a standard changes what can be done about it. A standard can be written down, applied to every outgoing request, and checked by somebody other than the author.
A workable standard fits comfortably on a single line. Every request that asks for work names the finished state, the boundary of scope, the accountable person, the date and time, and whether questions should be raised before starting.
Templates carry that standard without requiring anyone to remember it. A ticket form that will not submit without a definition of finished changes behaviour more reliably than a training session on writing.
Enforcement matters more than instruction in this area. Writing habits are formed by what gets returned unaccepted, not by advice about how to write better.
The check also runs in the other direction. Asking a recipient to restate the request in their own words before starting exposes divergence while it is still easy to correct. Disciplined approaches to making written instruction reliable across a team place that read-back step inside the workflow instead of leaving it to individual diligence.
The read-back takes very little time and produces two useful results. It corrects the recipient where they misread, and it corrects the sender where the wording genuinely allowed the reading.
What Changes When Requests Are Specified
The first visible change is the disappearance of an entire category of correction. Work that used to come back wrong now comes back different only where genuine judgment was involved.
The second change is a shift in when questions arrive. Specified requests generate questions at the start, when answering them takes minutes, rather than at delivery, when answering them means starting again.
The third change is quieter and considerably larger. Managers stop discovering that their teams misread the priority, because priority stated inside a request is much harder to misread than priority implied by tone.
A fourth effect appears in the practice of delegation. A manager who cannot specify an outcome cannot hand it over, and quietly retains tasks that should have moved. Writing the instruction is the act that makes handing it over possible at all.
A fifth effect appears in hiring and onboarding. New staff reach useful output faster where requests carry their own standard, because they are not required to infer house conventions from a handful of examples.
None of this requires longer messages than the ones already being sent. Specified requests are usually shorter than vague ones, since vagueness gets padded with background supplied in place of a decision.
Precision in writing also survives the departure of the person who wrote it. Instructions that carry their own standard remain usable when the author changes role, changes team, or leaves the business entirely.
Institutional memory is largely made of written requests and the results they produced. Where the requests were vague, the record explains nothing to whoever inherits the work.
The change is measurable in a rough but usable way. Counting how often finished work is sent back for a second attempt, and reading the original request each time, gives a manager a direct view of their own precision.
The awkward feature of this argument is that it locates a quality problem in the manager rather than in the team. Output that varies is far easier to explain as inconsistent effort, and that explanation leaves the writing entirely untouched. A business that inspects its own instructions before it inspects the work produced from them will find most of the divergence upstream of the person being corrected. Writing is not the soft end of management. It is the point at which intent becomes specification, and everything downstream inherits whatever precision was present there.
Frequently Asked Questions
How can you tell whether a request was clear enough?
The only reliable test is the work that came back. Where two people produced different results from the same wording, the wording permitted both, regardless of how obvious it felt to the author. Reading the original request after a piece of work is rejected, and asking whether the rejected version was a defensible reading, answers the question directly. That habit tends to be more useful than asking recipients whether they understood.
Does specifying every request slow a busy manager down?
Specifying moves the thinking earlier without adding to it. The decisions involved are ones the manager will have to make eventually, either before the work starts or after it comes back wrong. Front-loading them costs a few minutes and removes a full production cycle from the failure case. Managers who report that it slows them down are usually reporting that they had not made the decisions at all.
What should a written request always contain at minimum?
A finished state, a scope boundary, an accountable name, a date with a time, and a rule about questions. The finished state matters most, because it converts a direction of travel into a destination. The rule about questions matters more than it appears, since it determines whether the recipient stops or proceeds when something unexpected shows up. Anything beyond those five items is context rather than instruction.
Is verbal instruction ever acceptable for small tasks?
Speaking is fine for tasks where a wrong result costs little and gets noticed immediately. Anything that will take more than a short session, or that will be inspected by someone other than the requester, benefits from being written. Writing forces the specification that speech allows a person to skip. A short written summary after a verbal request captures most of the benefit at very little effort.
How should a team introduce a writing standard without resistance?
By putting it inside the tools rather than announcing it as a policy. Forms and templates that require the missing fields produce the behaviour without asking anyone to change their habits deliberately. Standards presented as personal criticism of writing ability tend to be resisted, while standards presented as a required field are simply completed. Consistency of enforcement matters far more than how the standard was introduced.
What if the work still comes back wrong after specifying?
That outcome is informative rather than a reason for discouragement. Where the request genuinely allowed only one reading, the failure sits in capability, workload or attention, and each of those has a different remedy. Where the request allowed two readings after all, the specification needs one more clause. Separating those two cases is the whole point of writing the instruction down in the first place.
No comments:
Post a Comment