Technical writers keep first-person pronouns out to maintain objectivity and credibility.

Should I spell out “I” in technical writing? In most professional contexts, the answer is simple: never. The reason is straightforward too—technical writing aims to inform with clarity, precision, and a tone that centers the content, not the writer. When you slip in a first-person pronoun, you risk pulling attention away from the subject matter and onto the author. Let me explain how this plays out in real docs, and how you can keep the focus razor-sharp without sounding stiff.

What happens when “I” sneaks in

• The culprit is subjectivity. If a sentence says, “I think this update fixes the bug,” the reader may question authority or objectivity. In manuals, guides, and formal reports, readers trust the facts and the procedures—not the writer’s personal opinion.

• Voice conflict. Technical documents thrive on consistency: a steady voice that serves the content. First-person phrasing can clash with the neutral, factual tone most readers expect in manuals, white papers, and API docs.

• Reader friction. When you start with “I,” the reader may wonder who is speaking and why. The cognitive load goes up just enough to be a tiny distraction from the steps, definitions, or specifications you’re delivering.

A quick contrast: how to frame statements without “I”

• Bad: “I will walk you through configuring the device.” Bad for formal docs; it pulls the spotlight onto the writer.

• Good: “This guide explains how to configure the device.” or “To configure the device, follow these steps.” The emphasis stays on the action and the user’s outcome.

• Bad: “I recommend enabling two-factor authentication.” Bad for a user manual; it sounds like a personal suggestion.

• Good: “Enable two-factor authentication to improve security.” This states the action and its value without tying it to the author’s voice.

What about “we” and a more conversational tone?

• “We” can be a useful bridge in some brands. It creates inclusivity and a sense of collaboration. In many corporate handbooks or product docs, that inclusive voice can feel human without crossing into personal pronouns.

• Still, in strict technical writing, “we” is often used sparingly or avoided in favor of neutral constructions. If your style guide allows it, use it purposefully — and keep it consistent.

• If in doubt, default to third-person or passive-like constructions. For example, “The installer checks for updates” keeps the focus on the process, not the author or the team.

Solid alternatives that keep the reader at the center

• Use the passive or agentless form sparingly but effectively. The action remains clear, and the sentence reads as objective:

• Passive: “The firmware is updated by selecting Settings > Update.”

• Active, without “I”: “Select Settings > Update to update the firmware.”

• Use imperative constructions for procedures:

• “Open the file, then click Save.” This is direct, unambiguous, and widely used in manuals.

• Use neutral nouns to foreground the process:

• “The installation process requires a valid license” instead of “I will guide you through the installation.”

• Address the reader with “you” when giving direct instructions, but avoid turning the sentence into a personal statement:

• “You should verify the checksum after download.” It speaks to the reader without implying the writer’s personal stance.

What to do in your writing today (practical tips)

• Do a quick pronoun audit. After drafting, scan for first-person pronouns. If you spot “I,” consider rephrasing to remove it.

• Favor action-forward sentences. Lead with the action, then the result: “Install the driver, then reboot the system.”

• Tie content to outcomes, not opinions. If you must reference a recommendation, phrase it as a protocol or standard:

• “The standard practice is to enable automatic updates.”

• Build consistency day by day. Once you settle on a voice (neutral/impersonal or a light, brand-tailored tone), apply it across the document to avoid jarring shifts.

• When your brand voice truly calls for a warmer touch, do so with care. A light, reader-friendly tone can coexist with formality, but keep the explicit use of “I” out of core technical sections.

A few real-world examples you can adapt

• Procedures and steps

• Bad: “I will show you how to configure the network settings.”

• Good: “This section shows how to configure the network settings.”

• Explanations and rationale

• Bad: “I believe this approach minimizes risk.”

• Good: “This approach minimizes risk by reducing exposure to…”

• Troubleshooting

• Bad: “I think the error is caused by a misconfiguration.”

• Good: “The error is typically caused by a misconfiguration in the settings.”

When is it okay to bend the rule, if ever?

• Some user-facing chatty guides or developer docs aim for a friendly, approachable voice. If your style guide explicitly permits occasional first-person references to build rapport, keep them rare and purposeful. A tiny nod here and there can humanize the content without sliding into personal opinion.

• In tightly regulated contexts—safety manuals, compliance reports, or critical infrastructure docs—the objective tone wins. In those cases, I’d err on the side of avoiding “I” altogether.

A short checklist you can keep at your desk

• Is the sentence centered on actions and outcomes, not the author? Yes → keep it changes in mind.

• Does it rely on singular, personal perspective? If yes, rework.

• Is there a direct instruction to the reader? If yes, consider “you” or imperative, not “I.”

• Does the document feel credible, precise, and neutral? If not, tighten up the tone and remove any first-person phrasing.

• Have you aligned with your brand’s voice guide? If your guide says “avoid I,” you should follow it.

The bigger picture: why this matters

• Trust and authority. Readers expect manuals, guides, and reports to be reliable. A detached, objective voice reinforces that trust.

• Clarity and focus. When you strip away the writer’s personality, the content becomes easier to scan, especially in long documents with steps, checks, and specifications.

• Consistency across the product ecosystem. One doc set that adheres to the same voice model feels cohesive to the reader, whether they’re in a user guide, a developer API doc, or a formal report.

A final nudge: keep the human touch, but not at the expense of precision

You don’t have to sound robotic to stay professional. It’s perfectly fine to use a friendly tone, explain concepts clearly, and acknowledge user needs. The trick is to keep the emphasis on the material—what the user does, what they achieve, and how the system behaves—without turning the author into the focal point.

If you walk away with one idea, let it be this: in technical writing, the first-person “I” tends to distract and diminish objectivity. So, hold back on “I,” lean into neutral language, and let the content lead the narrative. It’s a small shift with a big payoff—clearer manuals, smoother onboarding, and a reader experience that feels trustworthy from the first line to the last.

And if you’re ever unsure, the simplest test is this: read the sentence aloud and ask, who is the focus—the writer or the content? If it’s the writer, you probably want to rework it. When you get comfortable with that approach, you’ll notice a more confident, consistent voice across your technical material—and that’s something readers notice, even if they don’t name it.