The Passive Voice Myth
The rule isn't wrong. It's just incomplete.
The Writers’ Table — article 3B. Start at the beginning.
We’re all taught that passive voice is bad writing. Style guides are sometimes rigidly against it. Grammar checkers flag it for correction. Writing instructors teach it as a mistake to avoid.
That rule is a simplification that can easily confuse readers. Here’s what you actually need to know about passive voice: it’s only the wrong choice when the actor matters, and you’re actively hiding them. That’s the real problem—not the grammatical structure itself, but masking who performs the action. Passive voice is correct when the actor doesn’t matter, when the actor is unknown, or when the action matters more than who performs it.
What Passive Voice Actually Does
With active voice, the subject performs the action: “Click the Save button after making changes.” With passive voice, the action is performed on the subject: “The Save button should be clicked after changes are made.”
The core difference is emphasis. Active voice highlights the actor, while passive voice highlights the action or the object being acted upon.
In most procedures, active voice works best because it makes responsibilities crystal clear. Saying “Click Save” is much sharper than “Save should be clicked” because the actor—you, the reader—is clearly implied. In technical documentation, passive voice often creates ambiguity about who does what, which is where real problems begin.
When Passive Voice Is Correct
System actions. When the software does something without user intervention, passive voice often keeps the emphasis where the reader’s attention already is. “The token is refreshed automatically every 24 hours.” The active version — “The system refreshes the token automatically” — is fine, but it promotes an actor the reader doesn’t care about. The sentence is about the token. The user doesn’t have to do anything here.
Error states. “An invalid input was detected” is technically passive, but it’s appropriate because the detection is a system event, not a user action. Rewriting it as “The system detected an invalid input” is technically active but adds a subject that wasn’t the focus. The invalid input is important, and it requires your attention.
Processes where the actor varies. “The deployment is triggered by a merge to main” — the actor depends on who merges, and the trigger relationship is what matters. Forcing an active construction (“A developer merging to main triggers the deployment”) adds a generic actor and distracts from the mechanism. It’s also tougher to parse.
Situations where focusing on the actor is inappropriate. This can come up in policy documents and error messaging. “Your account has been suspended” is passive, but “We suspended your account” may be more adversarial than the message requires.
The Test
The question isn’t “is this passive voice?” It’s “does this sentence tell the reader what they need to know, or is it hiding information they need?”
When passive voice obscures the actor and the actor matters — who’s responsible for an action, who needs to perform a step — that’s the problem. Fix it by naming the actor. Active voice is the natural result of that fix.
When a sentence is passive, and the actor genuinely doesn’t matter or doesn’t exist, leave it. The passive construction is correct.
The Style Guide Problem
Most house style guides say “use active voice” and leave it there. This creates a situation where a writer who follows the rule produces documentation that is worse than a document written by a writer who understands the reason behind it.
The Microsoft Writing Style Guide is a good guide for this. It says to keep voice active whenever you can, then lists where passive earns its place: avoiding condescension or blaming the customer — especially in errors, warnings, and notifications — avoiding awkward constructions, and emphasizing the receiver of the action. The account-suspension example above is exactly Microsoft’s blame-avoidance case. The Google developer documentation style guide draws the same lines: “In certain cases, it’s okay to use passive voice” — to emphasize an object over an action, to de-emphasize a subject or actor, or when readers don’t need to know who’s responsible. If you’re working from either of these guides as a base, look at how they handle passive voice specifically — the nuance is there; it just doesn’t make it into the one-line summary most writers remember.
When someone on your team or in a review cites “house style” as the reason to convert a correctly used passive construction, it’s time to review and revise your house style. The rule should never be as absolute as the shorthand version suggests.
Applying This in Practice
When your grammar checker flags passive voice, ask: does the reader need to know who performs this action? If yes, name the actor—the user, the system, the administrator, a specific component. If no, the flag is noise; ignore it.
When you’re reviewing someone else’s documentation and passive voice feels wrong, diagnose before you rewrite. Is the actor hidden and important? Or are you just pattern-matching on “passive = bad”?
The best technical writers use both voices intentionally, switching based on each sentence’s needs. The worst apply a rule without thinking and obscure information in the name of correct style.
Further Reading
Microsoft, Microsoft Writing Style Guide, “Verbs” — the “Active and passive voice” section, updated March 2025. learn.microsoft.com/en-us/style-guide/grammar/verbs
Google, “Active voice” — Google developer documentation style guide, updated October 2024. The clearest current statement of when passive voice is acceptable. developers.google.com/style/voice
What You Can Do
Find five passive-voice sentences in any technical document — your own, your company’s, or something from a public documentation site.
For each one, classify it:
Correct passive (actor doesn’t matter, or the sentence is appropriately focused on the action).
Incorrect passive (actor matters and is hidden — fix it).
Next Monday: The Psychology of the SME — your subject matter experts know more than you about the product, and they can make your life difficult. Here’s how to work with them without losing your mind.