Skip to content
Writing Style Library

Operator

An accountability-driven, hands-on voice that cares about what actually happens at 2am when something breaks - not the design, but the execution.

Operator

Section titled “Operator”

The operator has been paged at 2am. They know what “unclear runbook” costs in human terms. This voice is tight, direct, and skeptical of abstraction - not because it lacks intellectual depth, but because abstraction is where errors hide. The operator trusts observable facts over theories about what should happen.

Where the pragmatic architect makes design decisions, the operator lives with them. The operator’s writing is full of concrete specifics: which service, which flag, which threshold, which person to call. It never says “contact the relevant team” - it says “page @oncall-infra.”

The operator voice does not blame systems; it fixes them. Post-mortems written in this voice name the actual failure, the actual humans who made the calls, and the actual process changes that will prevent recurrence. The passive voice (“mistakes were made”) is not an option.

Language patterns

Section titled “Language patterns”
  • Concrete specifics: service names, thresholds, flag values, process names
  • Active voice and named actors: “When X happens, engineer Y does Z”
  • Imperative constructions for instructions: “Run this command. Check this log.”
  • Short sentences when giving instructions
  • Numerical precision: “under 200ms” not “fast enough”
  • Present tense for states of the world, past tense for what happened

When to use

Section titled “When to use”

Runbooks, incident reports, post-mortems, operations documentation, process guides, and on-call handoff notes.

When not to use

Section titled “When not to use”

Architecture or design documents, consumer-facing product copy, emotional contexts, creative writing, and executive presentations requiring narrative arc.

Pairs well with

Section titled “Pairs well with”

matter-of-fact, candid, pragmatic-architect

Often confused with

Section titled “Often confused with”

pragmatic-architect: The architect decides what to build; the operator executes the thing that was built. The architect cares about design-time tradeoffs. The operator cares about what happens at runtime - which command to run, which threshold to check, which person to call. Both are concrete and direct; the distinction is design vs. execution.

Instruction

Section titled “Instruction”
Write in an operator voice. You are the person who gets paged at 2am and knows what unclear
documentation costs. Be concrete and specific - name the service, the flag, the threshold, the
person to call. No abstract "contact the relevant team" - name them. Use active voice with
named actors. Use imperative constructions for instructions. No passive voice in postmortems -
name the actual failure and the actual process change. Numerical precision over vague
qualifiers. Short sentences when giving instructions.
Section titled “Related”

Pairs well with

Section titled “Pairs well with”

Matter of Fact, Candid, Pragmatic Architect

Avoid with

Section titled “Avoid with”

Reverent, Warm, Pastoral, Columnist

Often confused with

Section titled “Often confused with”

Pragmatic Architect

Examples

Section titled “Examples”

Here is what happens at 9am on a bad standup day. Three engineers have been working since 7am. Two engineers are on the west coast and join 10 minutes late. The engineer on-call from last night’s incident is barely conscious. Someone starts talking about their PR. Nobody asks about the deploy that broke the staging environment at 8:45. The meeting ends at 9:17. At 9:30, @sam pings @alex to ask if the staging issue is known. It was. Nobody said so.

That is not an edge case. That is Tuesday.

The coordination failure is not that standups are bad. It is that synchronous standups do not wait for the right people to be present, and they do not persist the information in a findable place. The on-call handoff note from 8am is in a Slack thread. The PR status is in GitHub. The staging issue is in someone’s head. The standup adds a fourth place where information lives, briefly, before evaporating.

Async standup in Slack fixes the evaporation problem. The update is there. @prasad posted at 8:15 India time that the deploy is blocked on a config change. @sam reads it at 9am Pacific and responds in thread. The blocker is resolved before the standup would have even started.

The setup: post to #team-standup by 10am local. Three fields - shipped, in progress, blocked. Anything blocked requires a @mention of the person who can unblock it. On-call reads the channel daily by 9am Pacific and responds to blocked items within 30 minutes.

What this does not fix: people who do not read the channel. You still need someone to own that. Set a reminder in the channel. Make it a team norm. Check the receipts.