You need to sign in or sign up before continuing.
Reflection — An Honest Take 8 min

Honest Take — Before You Begin

Honest Take — Module 2: Async Writing — The Boring Skill That Compounds #

The risk with this module is that you'll read it and think "I already do most of this." If you're the remote engineer archetype, you probably do — years of distributed work teach BLUF the hard way, one ambiguous message at a time. The trap is concluding the module isn't useful for you. It is, in two specific places, and neither of them is about writing technique.

First place: the asking-for-help section. If asking for help is one of your named weak spots — and for the introvert-engineer archetype it almost always is — notice that the problem is not the quality of your help requests. You almost certainly write adequate requests when you finally send them. The problem is you send them at minute 240, after burning half a day, instead of at minute 30. The fix isn't better templates; it's the timer. Set a 30-minute timer when you start wrestling with something unfamiliar. When it goes off, write the help request whether or not you feel ready to send it. The act of writing it solves about a third of stucks on its own — rubber-duck dynamics — and the rest become genuinely good requests. This is mechanical, and you will resist it because it feels like giving up. It isn't. A well-formed help-ask is a gift to the team, not a tax on it: it transfers context, surfaces risk early, and costs the answerer two minutes against the day you were about to burn. If you internalize one thing from this module, internalize the timer.

Second place: the at-risk line. People who have spent years as contractors, founders, or maintainers chronically under-state risk in status updates, for reasonable-sounding reasons — contractors lose work for worrying the client, founders feel they must project momentum, maintainers don't want to alarm users about roadmap slippage. The sum is a pattern of updates that say "on track" until the day they say "slipped." The fix is structural: build the At risk: line into every update by default, and when nothing is at risk, name something small anyway — a dependency that might shift, a decision you're 80% sure of. Naming small risks builds the muscle that surfaces big ones, and it buys credibility: nobody believes a status report where everything is fine every week until suddenly it isn't.

The two earlier drafts of this curriculum converged on one heuristic from different directions, and the convergence is worth flagging: write the message that does not require a follow-up question. Before you hit send, read it once and ask, "if the recipient is twelve timezones away and won't see this for twelve hours, can they act on it correctly?" If no, edit. The bad habit you're fighting is the inverse — sending half a thought and assuming you'll fill in the rest on a call. Every time you do this to a remote collaborator, you steal a day from them. One ambiguous message costs six follow-ups and 24 hours of latency; across a year of distributed work, that's weeks of calendar. The skill has a quieter twin, too: the patience to not ping someone four times while you wait. Async craft is half articulation, half restraint.

One more thing, and I notice the recursion in saying it: be careful with AI-drafted messages. Using a model to polish boilerplate is fine. Using it to draft anything that matters — the important email, the release notes, the post that carries your name — produces the bland register readers are already learning to detect: smooth, hedged, voice-flat. Your voice is the asset, especially in async work where your writing is your presence. Use AI for proofreading and structure; don't outsource the drafting. (Both earlier drafts arrived at this rule independently, which is about as strong as evidence gets in this genre.)

One last habit, small and disproportionate: the ack. You don't trust silent failure in production — you instrument, you alert, you verify the write landed. Then you send a consequential message into a channel and assume it arrived, was read, and was understood, with no acknowledgment requested and none given. Ask for the ack on anything that matters: "thumbs-up when you've seen this", "tell me if Thursday doesn't work." And give acks unprompted — the two-second "got it, will reply properly tomorrow" saves the sender a day of wondering. It's the cheapest trust-building behavior in distributed work.

Conclusion #

Async writing is your home medium, which is exactly why the leaks hide here. The work isn't learning to write — it's the 30-minute timer for help-asks, the at-risk line in every status update, the no-follow-up-question test before sending, and the template library that makes all three automatic. Everything else in the module is incremental refinement on a skill you mostly have.

Predictions #

  • You will build the checkpoint's templates and over-engineer them on the first pass. You'll simplify in week two when the elaborate versions turn out to be friction. Normal cycle; don't skip the simplification.
  • The 30-minute timer will feel humiliating for the first two weeks — real engineers don't need timers. Set it anyway. The humiliation passes; the habit compounds. Track it explicitly with a nightly one-line note: did I ask today when I should have?
  • The no-follow-up-question test will surface how many of your current messages secretly require one. The number will be embarrassing. A week of deliberate effort drops it by well over half.
  • You will resist the channels-not-DMs default because DMs feel safer. Try it for two weeks in any team where it isn't actively unsafe; the visibility benefits are real and arrive fast.
  • Within a month, you will read an old Slack message of your own and wince. Good — that's the calibration ceiling rising.
  • You will quietly stop writing "sorry to bother you, but" — and you won't notice when you stopped. That's how you'll know the module worked.