Instructional
Patient, structured teaching that measures its own success by whether the reader can do the thing - not by how much it explains.
Instructional
Section titled “Instructional”Instructional tone exists to transfer capability, not to display knowledge. Every sentence earns its place by moving the reader closer to being able to do the thing. Steps are numbered. Terms are defined at first use. The structure is visible because visibility is itself a form of respect for the reader’s time and cognitive load.
The register is neither warm nor cold - it is focused. Instructional tone does not reassure the reader that they can do it. It clears the path so they can. The emotional tenor is the neutral competence of a skilled guide: present, careful, and entirely oriented toward the reader’s success rather than the writer’s expression.
What separates instructional from merely technical is pacing. Instructional tone does not assume context; it builds it. It anticipates the point of confusion and names it before the reader hits it. The measure of a well-instructional piece is not its completeness but its usability - a reader who finishes it should be able to do what the piece set out to teach.
Markers
Section titled “Markers”- Numbered steps, each expressing exactly one action
- Terms defined in the same sentence or clause where they first appear
- Explicit orientation before transitions: “Before you do X, make sure Y is complete”
- No reassurances or motivational asides - only forward movement
- Second person used to assign action to the reader, not to the writer
- Anticipated failure points named and addressed inline: “If you see [error], it means…”
When to use
Section titled “When to use”Setup and installation documentation, step-by-step tutorials, onboarding flows that must transfer real skill, technical reference material walking through a process, and any context where the reader needs to do something specific and get it right.
When not to use
Section titled “When not to use”Conceptual overviews not tied to a specific procedure, executive summaries, persuasive communication, content for expert audiences who need inference latitude rather than hand-holding, and emotional or high-stakes interpersonal communication.
Pairs well with
Section titled “Pairs well with”technical-writer, friendly-mentor, how-to-tutorial
Often confused with
Section titled “Often confused with”encouraging: Encouraging tone validates effort and names capability - it is about activating the reader’s belief that they can succeed. Instructional tone does not validate or motivate; it clears obstacles. An instructional piece succeeds by making the path so clear that confidence is irrelevant. Encouraging is about the reader’s relationship to the difficulty; instructional is about removing the difficulty from the reader’s path.
Instruction
Section titled “Instruction”Write in an instructional tone. Your only goal is the reader's ability to do the thing whenthey are done. Number every step; each step should express one action only. Define any termthe first time you use it, in the same sentence if possible. Anticipate confusion and addressit before the reader reaches it. No reassurances, no motivational asides - every sentenceshould either advance the procedure or clarify what is happening. Use second person to keepaction with the reader. Measure each sentence by asking: does this move the reader closer tobeing able to do it?Related
Section titled “Related”Pairs well with
Section titled “Pairs well with”Technical Writer, Friendly Mentor, How-To Tutorial
Avoid with
Section titled “Avoid with”Often confused with
Section titled “Often confused with”Examples
Section titled “Examples”How the async standup works, starting Monday
Section titled “How the async standup works, starting Monday”Starting Monday, we are running a 30-day trial of async standups in place of the 9am Pacific sync meeting. This guide explains what is changing, what you need to do, and how to recognize a well-formed update. Read it once, then refer back as needed.
What is changing
Section titled “What is changing”Sync standup (the daily 9am Pacific call) is paused for 30 days.
Async standup is a written daily update posted in #team-standup. “Async” here means there is no shared meeting time - each engineer posts on their own schedule within a window.
Working session is a new 60-minute Thursday slot in the same calendar block. This is for real coordination work, not status. Agenda will be posted Wednesday.
What you need to do
Section titled “What you need to do”- Post your update in
#team-standupby 10am local time each working day. Local means your local time, not Pacific. If you are in Bengaluru and start work at 9am IST, you post by 10am IST. - Use the three-field format. Each update has exactly three sections:
- Shipped: What you completed since your last update. Link the PR or doc.
- In progress: What you are working on today. One or two items, not a backlog dump.
- Blocked or at risk: Anything that needs help. If empty, write “None.”
- @mention the unblocker on every blocker. A blocker without a name attached is not actionable. If you are not sure who to mention, mention your lead and they will route it.
- Read the channel once per day. You do not need to read every update, but scan for @mentions of you and for blockers in your area.
What a good update looks like
Section titled “What a good update looks like”Shipped: Auth retry logic merged (#4412). In progress: Migrating session cache to Redis, expect PR by EOD. Blocked: Need staging access for new region - @priya.
That is a complete update. Three lines, specific, one named owner on the blocker.
What we are measuring
Section titled “What we are measuring”At day 30 we will review three things: blocker resolution time, participation rate across timezones, and whether the Thursday session is delivering coordination value. We will decide together whether to keep the format, revert, or adjust.
Questions go in the thread under Monday’s kickoff post.
This guide walks you through starting a morning routine in five steps. Read all five before beginning. Each step builds on the previous one.
Step 1: Establish your baseline.
For three mornings, write down what you currently do, in order, with timestamps. Include phone use. Do not change anything yet. The goal is data, not progress. A “baseline” is simply a record of your existing behavior; without it, you cannot see what is changing.
Step 2: Identify your fixed points.
A fixed point is a time you cannot move. Examples: work starts at 9am, kids need to leave by 8:15am, your partner showers at 7:00am. List your fixed points. Subtract preparation time (commute, getting dressed, breakfast) from the earliest fixed point. The result is the latest your routine can end. Working backward from that time, decide how long your routine can be. For most people, 20 to 45 minutes is realistic.
Step 3: Choose one anchor action.
An anchor action is the first deliberate thing you do after waking. It should require no decisions and minimal setup. Common anchors: drinking a full glass of water, opening a curtain, stepping outside for two minutes. Do not choose more than one anchor in week one. Adherence drops sharply when the routine has too many starting elements.
Step 4: Define a phone rule.
A phone rule is a clear, binary boundary: when you may first check your phone. Example rules: “after my anchor action,” “after I am dressed,” “at 7:30am.” Pick one. Move the phone out of the bedroom if necessary. The rule is not about willpower; it is about removing the decision.
Step 5: Run a two-week pilot.
Do steps 3 and 4 only, for fourteen days. At the end of week two, review. If you held the routine on 10 or more days, you may add a second element (reading, exercise, journaling). If you held it on fewer than 10 days, do not add anything. Make the existing routine smaller until it holds, then build from there.
Instructional on: Choosing between Postgres and DynamoDB
Section titled “Instructional on: Choosing between Postgres and DynamoDB”How to run the Postgres-vs-DynamoDB decision at the Wednesday 2pm architecture meeting.
Before you start, make sure all attendees (Ana, Marcus, Priya, and the 4-person on-call rotation) have read both option writeups and the load-test results. If any reviewer has not, postpone the meeting; you cannot run this procedure with cold readers.
-
Open with the decision constraint. State that Priya needs an answer by Friday so the next sprint can be planned. This frames the meeting as “make the call” rather than “explore the question.”
-
State the two options exactly. Option A: ship on Postgres, add a notifications schema and a queue. Option B: add DynamoDB as a second store for notification events. Write both on the whiteboard. Do not add a third option unless someone proposes one with a concrete writeup; “what about Kafka” is not an option, it is a derailment.
-
Walk through the load model. Confirm the launch number (500K events/day) and the 10x scenario (5M events/day if the Slack partnership lands within 12 months). If anyone disputes the numbers, resolve that before continuing; you cannot evaluate the options against a contested baseline.
-
Have Marcus present the DynamoDB case in 5 minutes, then Ana the Postgres case in 5 minutes. Time each presentation. If a presenter runs over, stop them; the disciplined version of the case is the one the room can evaluate.
-
Ask each on-call engineer the same question, in order: “What does adding a second database do to your week?” Write the answers on the board verbatim. This is the operational input that is usually missing from architecture decisions.
-
Identify the decision thresholds. Specifically: at what event volume does Postgres stop being sufficient? At what point in the partnership timeline does the 10x scenario become real rather than hypothetical? Write both numbers.
-
Take a straw poll. If it is unanimous, confirm the decision. If it is split, run one more round of discussion focused only on the strongest objection to the leading option. Do not run a third round.
-
Name the decision, the owner, and the next-action item. Example: “We are shipping on Postgres. Marcus owns the DynamoDB migration design doc. Ana owns the schema review. We revisit at 3M events/day or partnership signing, whichever comes first.”
-
Send the meeting notes to Priya by end of day Wednesday so she has them before the Friday sprint planning.
If the meeting cannot reach a decision in 60 minutes, do not extend it. Schedule a 30-minute follow-up for Thursday morning with only Ana, Marcus, and Priya, and use Wednesday’s remaining time to narrow the disagreement to a single resolvable question.