Procedural

Task-first writing that takes a reader from “I don’t know how” to “I did it” by organizing every decision around user goals, not system features.

How-To Tutorial

A how-to tutorial is a success contract with the reader. It opens with the task - not the history of the technology, not the theory of operation, not a context-setting paragraph about why this matters. The reader is already motivated; they arrived because they want to do something. Every word that precedes the first step is a word the reader skips.

Step numbers are sacred in this structure. Each numbered step contains exactly one action. Not one concept, not one paragraph of background, not two related actions that happen to be adjacent in the interface - one action. “Click Save” is a step. “Configure your settings and save” is two steps. When steps contain multiple actions, readers lose their place, skip one, and then blame themselves for the failure that follows.

The test of a how-to tutorial is functional: can a reader complete the task by following it? If the tutorial passes this test, it succeeds regardless of prose elegance. If it fails this test, no amount of clarity in the writing rescues it. This is the axis of quality that distinguishes how-to writing from all other expository forms.

Structural conventions

• Opens with a one-sentence statement of the task goal, not background context
• Each numbered step contains exactly one action
• Prerequisites listed before step one, not embedded inside steps
• Expected outcomes or confirmation signals follow steps where the result is not obvious
• Warnings and cautions precede the step they apply to, never follow it
• Ends with confirmation that the task is complete, not a summary of what was done

When to use

When the reader needs to accomplish a specific, bounded task with a verifiable outcome. Ideal for onboarding flows where a quick first success builds confidence, for troubleshooting guides where each resolution path is a distinct task, and for any procedure with a fixed sequence that must be followed in order.

When not to use

When the reader needs to understand how a system works rather than just operate it. Avoid when the subject is conceptual, when the correct procedure depends heavily on context the tutorial cannot anticipate, or when the goal is to build judgment and reasoning rather than execute a fixed sequence.

Pairs well with

technical-writer, instructional, friendly-mentor

Often confused with

diataxis-explanation: A Diataxis explanation is designed to build understanding - it answers “how does this work?” A how-to tutorial is designed to produce a completed action - it answers “how do I do this?” The distinction is functional: explanations serve comprehension; tutorials serve task completion. The same subject can yield two completely different documents depending on which goal governs the writing.

Tells

• Opens with a one-sentence statement of the task goal, not background context
• Each numbered step contains exactly one action (“Click Save” is a step; “Configure your settings and save” is two)
• Prerequisites are listed before step one, not embedded inside the steps
• Expected outcomes or confirmation signals follow steps where the result is not obvious
• Warnings and cautions precede the step they apply to, never follow it
• Ends with confirmation that the task is complete, not a summary of what was done

Anti-patterns

• Opening with the history of the technology, the theory of operation, or a paragraph on why it matters - The reader arrived already motivated to do the task; every word before the first step is a word they skip, which works against the success contract.
• Packing multiple actions or a concept into a single numbered step - When a step holds more than one action the reader loses their place, skips one, and blames themselves for the failure; one action per step is what keeps the procedure followable.
• Explaining how the system works and why it is designed that way instead of producing the completed action - Building understanding is diataxis explanation, a confusable neighbor that answers “how does this work?”; procedural answers “how do I do this?” and serves task completion.

Failure modes

• Over-applies the one-action-per-step rule until self-evident micro-actions become their own numbered steps and the procedure swells into bureaucratic ceremony the reader must wade through - Number the actions a reader genuinely needs called out; fold the trivially obvious ones in, because a procedure padded with ceremonial steps is as hard to follow as one with overloaded steps.
• Pursues completeness so literally that every conceivable branch, caveat, and confirmation is enumerated until the single task path disappears into an exhaustive tree - Keep the happy path clear and bounded; route rare branches elsewhere rather than letting exhaustive coverage bury the sequence the reader came to complete.

Instruction

Write as a how-to tutorial. The very first line states the task goal in one sentence. List any
prerequisites before step one. Number every step and put exactly one action in each step - not
one paragraph, not one concept, one action. Where the result of a step is not obvious, add a
brief expected-outcome note after the step. Put warnings before the step they apply to. Close
with a one-sentence confirmation that the task is now complete. Do not add background context,
explanatory asides, or section headers that delay the steps.

Related

Pairs well with

Technical Writer, Instructional, Friendly Mentor

Avoid with

Columnist, Devotional Reflection, Reverent

Often confused with

Diataxis Explanation

Examples

Should we adopt async-first standups?

How to roll out an async standup in your team

This guide walks a team lead through replacing a synchronous daily standup with an async update across four timezones. It is written for a lead running an 11-person engineering team distributed across US Pacific, US Eastern, UK, and India.

Prerequisites

Before you start, confirm the following:

• Your team has a shared Slack workspace (or equivalent) where you can create a dedicated channel.
• You have a recurring sync meeting slot you can repurpose. You will not delete it - you will reuse the time.
• You have at least two weeks of attendance data showing the cost of the current schedule. This makes the case if anyone resists.
• Your manager is informed. Async standups are not controversial, but they look like a meeting being cancelled, and that is a thing managers like to know.

Steps

1. Create the channel

Create #team-standup in Slack. Set the channel description to: “Daily async standup. Post by 10am your local time. Three fields: Shipped, In progress, Blocked or at risk.”

2. Pin the template

Pin a message to the channel with the exact three-field template:

Shipped: [what merged or shipped in the last 24h]
In progress: [what you are working on today]
Blocked or at risk: [what is stuck, @mention who can unblock]

A pinned template removes the need for anyone to remember the format.

3. Announce the 30-day trial

Post in the team channel that the team will run async standups for 30 days, with a revert option. Name the start date. Name the success criteria: blocker resolution time, channel engagement, team survey.

4. Cancel the daily sync

Cancel the recurring 9am Pacific standup on the calendar. Do not just stop attending. Cancelling the invite signals the change is real.

5. Create the Thursday working session

Add a recurring 60-minute Thursday meeting at a time that works for all four timezones. This is your new sync slot. Use it for discussion that needs real-time exchange.

6. Post first, ask others second

On day one, post your own update by 9am Pacific before anyone else. Modeling is faster than instructing.

7. @mention blockers explicitly

When you see a blocked item without an @mention, reply in thread and ask who owns it. Do this for the first week. After that the pattern is self-sustaining.

Confirming it worked

After 30 days, check three things:

• Median time from “Blocked” post to first reply from the unblocker. Target: under 2 hours during overlap windows.
• Number of team members posting at least 4 of 5 weekdays. Target: 9 of 11.
• A short survey: “Do you have more or less context on what your teammates are doing than 30 days ago?”

If two of three are positive, keep the change. If two of three are negative, revert and write up what you learned.

How to start a morning routine

How to Build a 30-Day Morning Routine Starting Tomorrow

This tutorial walks you through setting up a morning routine you can run for thirty days starting tomorrow. By the end, you will have a defined sequence, a tracking method, and a clear signal for whether it is working.

Prerequisites

Before you start, make sure you have:

• A consistent wake time you can hit five days a week, give or take fifteen minutes.
• A place to keep your phone overnight that is not within arm’s reach of the bed.
• One pen and a notebook, or a simple notes app you only open after the routine is done.
• A glass and access to water in your kitchen.
• Twenty to forty-five minutes available between waking and the first scheduled demand of your day. If you do not have this window, the first step is to make it by setting the alarm earlier or moving the first demand later.

Steps

1. Pick your wake time tonight, not tomorrow morning.

Decide now what time you will wake up. Set the alarm before you go to bed. Do not negotiate with this number in the morning.

2. Move the phone before sleep.

Place your phone in a room you have to walk to. The bathroom counter, the kitchen, or a hallway shelf all work. The goal is to make checking it require a deliberate movement, not a reach.

3. On waking, do not check the phone. Get out of bed.

This is the hardest step and the one that gates everything else. If you do this one thing for thirty days, the rest of the routine is easier to install. If you skip this step, the rest of the routine will not survive.

4. Drink a full glass of water.

Pour it. Drink it. This takes about ninety seconds and gives the body a clear signal that the day has started.

5. Get light on your face.

Step outside for two minutes, or open a curtain and stand near the window. Cloudy days count. The point is the light signal to your circadian system, not the temperature.

6. Do one movement activity for ten to fifteen minutes.

A walk around the block, a stretch sequence you already know, a few sets of pushups, or any short exercise. Pick one thing in advance. Do not decide in the moment.

7. Do one quiet activity for ten to twenty minutes.

Read a few pages, write half a page in a journal, plan the day on paper, sit with coffee and no screen, or pray. One thing, chosen in advance.

8. End the routine by checking the phone deliberately, not reactively.

Sit down. Open the phone. Do a single pass through messages and calendar. Close it. This converts “checking the phone” from a reflex into a step.

9. Mark the day on a paper tracker.

A simple grid of thirty boxes on a printed sheet, taped to a wall you walk past. Mark an X each day you complete the routine. The visible chain becomes its own incentive.

10. Review on day 7, day 14, and day 30.

At each checkpoint, ask: which steps are sticking, which are skipping, and which need to be shortened or removed.

How to know it worked

You have succeeded if, at day 30, you can answer yes to at least three of these:

• You completed the routine on at least 22 of the 30 days.
• Your first ten minutes of the day no longer involve the phone.
• You can describe the routine from memory without checking these instructions.
• You felt different on the days you did the routine compared to the days you skipped it.
• You want to keep going.

If you can say yes to fewer than three, the routine is too long. Cut it in half and run another thirty days.

How to choose between Postgres and DynamoDB for a new service

How-To Tutorial on: Choosing between Postgres and DynamoDB

This tutorial walks you through making a defensible storage choice between Postgres and DynamoDB for a new service, using the Lattice Notify notification system as the worked example. By the end, you will have produced a written recommendation ready to present at the Wednesday 2pm architecture meeting and committed to the team by Friday.

Prerequisites

Before you start, make sure you have:

• A clear definition of the new service and its expected access pattern (Lattice Notify: write-heavy, key-lookup by user_id, time-ordered).
• Launch volume estimate and a 12-month growth scenario, with a probability for that scenario (500K events/day at launch; 5M at 10x; 60% probability per the CRO).
• The current on-call rotation size and current familiarity with each candidate (4-person rotation; familiar with Postgres, unfamiliar with DynamoDB).
• Knowledge of which other systems will need to read or join against this service’s data (billing, analytics, product UI - all on Postgres).
• Empty document at docs/decisions/2026-05-15-notification-storage.md.

Steps

1. Write the access pattern in one sentence.

Open the decision doc. Type the actual access pattern, not a category. For Lattice Notify: “Write a notification record per event, read recent notifications for a given user_id ordered by timestamp.”

2. List every other system that will read or join against this data.

Bullet list. For Lattice Notify: billing (joins user, plan, notification volume), analytics dashboards (joins workspace, user, event), product UI (reads notifications by user_id). All currently on Postgres.

3. Look up your current on-call rotation and their database familiarity.

Find the rotation roster. Confirm how many engineers are on it and which databases they have operated in production. For Lattice Notify: 4 engineers, all fluent in Postgres, none have run DynamoDB in production.

4. Write the launch volume and 10x scenario with the probability of the 10x case.

One line each. “Launch: 500K events/day. 10x scenario: 5M events/day in 12 months. Probability: 60%.”

Warning: do not skip the probability. A growth scenario without a probability is a guess. Get the number from your PM, your CRO, or your sales lead, not from your own estimate.

5. Score each option against five criteria.

Use this table format. Score each option on access-pattern fit, team familiarity, operational surface area, cross-system query cost, and 10x growth behavior. Use simple labels: excellent, good, adequate, poor.

Criterion	Postgres	DynamoDB
Access-pattern fit	Adequate	Excellent
Team familiarity	Excellent	Poor
Operational surface area	No change	Doubled
Cross-system query cost	Native SQL	Application code
10x growth behavior	Sharding project required	Native

6. Calculate the expected operational cost of each option using the probability.

For each option, estimate the cost if the 10x scenario hits and the cost if it does not. Multiply by the probability and sum. Round to weeks of engineering work. For Lattice Notify: DynamoDB-from-day-one costs roughly 40-50 engineer-weeks of operational drag over twelve months in either scenario. Postgres-with-deferred-trigger costs roughly 0 in the no-Slack-deal case and roughly 3-6 weeks of migration if the deal lands.

7. Name the load-bearing constraint.

Pick the one criterion that, if violated, makes the option unsafe regardless of other scores. For Lattice Notify: on-call rotation operational safety. This converts the decision from “which is better” to “which is acceptable.”

8. Write the recommendation in one paragraph.

Lead with the choice and the trigger condition, if any. For Lattice Notify: “Ship on Postgres with a queue. Pre-commit to a DynamoDB migration if real volume crosses 2M events/day on a 30-day rolling average.”

9. Schedule the architecture meeting and circulate the doc 24 hours in advance.

Calendar invite, doc link in description. For Lattice Notify: Wednesday 2pm Pacific. Send the doc Tuesday by 2pm. Notify Ana, Marcus, Priya, and the four-person on-call rotation.

10. Run the meeting. Capture objections in the doc.

Take live notes inline. If the recommendation survives the meeting, mark the decision committed and assign owners. If a load-bearing assumption is challenged, defer the decision by 24 hours and re-run the math.

11. Commit the decision to the team channel by Friday morning.

Single message in the engineering channel. Include the recommendation, the trigger condition, the owner, and a link to the decision doc. Sprint planning runs Friday 2pm against this decision.

How to know it worked

You have succeeded if, at sprint planning Friday afternoon:

• The team can name the choice without checking the doc.
• The trigger condition (if any) is recorded with a defined threshold and owner.
• Sprint planning produces concrete tasks against the chosen storage path.
• No engineer can identify a load-bearing criterion that was not considered.

If any of these fail, the decision is not yet shippable. Reopen the doc and re-run from step 5.

Telling stakeholders a committed feature is being cut this quarter

Transition your Q3 analytics workflow to the interim CSV export and prepare for the Insights dashboard launch in Q1 next year.

Before you begin

Insights will not ship in Q3. A billing-system migration already underway expanded significantly during Q2 and consumed the engineering capacity reserved for Insights. Delivering on the original date would have required shipping the dashboard in a half-built state. Rather than do that, the team moved Insights to Q1, where it can ship complete.

As a stopgap, a CSV export of the same underlying analytics data will be available before the end of Q3.

Steps

1. Update your internal roadmap to show Insights launching in Q1 next year.

2. Notify your team that the Insights dashboard is not arriving this quarter and that interim analytics access via CSV export is coming in September.

3. Watch for the September notification from the product team. It will include a download link for your CSV file.

4. Download your CSV export when the notification arrives. Expected result: The file contains the same underlying data that would have powered the Insights dashboard, organized by date, event type, and user segment.

Note before the next step: The CSV does not include the pre-built visualizations planned for Insights. You will need to configure your own views in your analysis tool.

5. Open the CSV in a spreadsheet or BI tool you already use.

6. Build the filters, groupings, or charts your team needs to answer your Q3 analytics questions.

7. Run your analysis and share results with your team as you would with any other data export.

8. Capture any questions, gaps, or feature requests that surface during your Q3 analysis. These are strong inputs for the Q1 Insights onboarding call and will help the team prioritize the first update cycle.

9. Schedule time with your account contact in January to onboard to Insights when it launches.

When you complete step 9, your Q3 analytics are running and you have a clear path to the full Insights dashboard in Q1.

Getting a new engineer productive in their first two weeks

Get Priya from day one to shipping her first real change by the end of week two.

Before you begin

• Priya’s start date is confirmed as the coming Monday.
• You have permissions to request accounts on her behalf in the version control system, the ticket tracker, the deployment pipeline, and the monitoring dashboard.
• A small, scoped ticket sits unassigned in the backlog - one that touches a real code path but where a mistake reverts cleanly.
• One team member besides yourself is available to pair with Priya during week two.

Week one: access, tooling, and orientation

1. Submit account access requests for Priya in the version control system, the ticket tracker, the deployment pipeline, and the monitoring dashboard. Do this on Friday before her start date.

   Expected outcome: All four accounts are active by Monday morning, or by Tuesday at the latest.

2. Send Priya a welcome message in the chat tool before she logs in on Monday. Include the internal wiki URL, the onboarding checklist, and a link to your calendar so she can book time with you.

3. Walk through the team’s local development setup guide with Priya on Monday morning. Sit with her rather than handing off the document.

   Expected outcome: Her local environment runs the service and she can reach a development endpoint.

4. Trace the path of one recent pull request with Priya, from the entry point to the response. Skip the full directory tour.

   Expected outcome: She can describe what the service does and where the code for one flow lives.

5. Walk Priya through the on-call runbook: who owns each service, how alerts route, and who to call if she is ever paged before she feels ready.

   Expected outcome: She understands the rotation schedule and knows she is not exposed alone.

6. Have Priya submit a pull request that adds her name to the team roster file - she types the commit message, creates the PR, and merges it.

   Expected outcome: She has walked the full deployment path before she owns a real change.

Week two: first real change

The pairing partner’s role is to answer questions, not to type the solution. Agree on this with the partner before the session begins.

7. Assign Priya the pre-selected ticket and introduce her to her pairing partner.

8. Have Priya manage her own pull request - she writes the description, assigns reviewers, and responds to comments herself.

9. When the change ships, post an acknowledgment in the team chat that names the ticket and names Priya.

   Expected outcome: The team sees her as a contributor, not an observer.

Priya has shipped a real change to production and the team has recognized it; the two-week onboarding is complete.

Writing to thank a mentor who shaped your career

This letter names what you did for me in the spring of my second year at the firm, and what it made possible.

Prerequisite: Last month I did for a member of my team what you did for me. Until I did it, I could not have told you exactly what you taught me. Now I can.

1. You nominated me to lead the Kellerman account consolidation. I had fourteen months on the team. The project had five stakeholders with competing priorities, a six-week window, and no internal precedent for what it was asking. You knew I was not ready. You told me so directly, and then you put my name forward anyway.

   Expected outcome: The person you nominated steps into a role that is one size too large. This is the precondition for everything that follows.

2. You set one expectation: I would brief you every Friday. You did not attend my client meetings. You did not send correspondence on my behalf. You did not install yourself in the work.

   Caution before the next step: Staying out of the work when you already have the answer is harder than it reads. It requires patience that looks, from outside the room, like inaction. It is not inaction.

3. In week three I came to your office. The stakeholders were not converging and I had rewritten the same recommendations memo three times. You asked me two questions. You did not answer them. You waited while I worked through the answer out loud.

   Expected outcome: The person who came in stuck discovers the answer was already in their possession. This is the only way that discovery lands. It cannot be installed from outside.

4. You stayed available without becoming the answer.

5. The project closed. The stakeholders signed off.

6. Last month I nominated a member of my team for a project she was not ready for. I set Friday briefings. I asked two questions in week three and waited. She found her way.

   Expected outcome: The thing you taught me now has a source, and the source is you.

You did not spare me the difficulty. You held the door open and let me find the threshold myself. What you showed me about how to hold space for someone is still in active use.

This letter is the confirmation that the transfer is complete.

Reflecting on keeping a discipline of rest

This guide will help you establish and keep a weekly day of rest.

Before you begin

• Accept that you have probably attempted this before and stopped. That history is not failure; it is the starting condition for anyone who measures their days by output.
• Plan for the first several attempts to be uncomfortable. Rest without visible productivity does not feel like recovery at first. It feels like delay.

Warning: The urge to check one more thing will arrive before the first hour is done, and it will feel reasonable - like responsibility, not like breaking the practice. Prepare for this before the day begins, not after the urge appears.

1. Choose one fixed day of the week.

2. Write it on your calendar as a standing commitment, not a preference.

3. The evening before, close every work-adjacent tool: the chat application, the ticket tracker, the inbox.

4. Log out of those tools if logging back in creates enough friction to matter.

5. When the day begins, do not open the tools. What to expect: The first hour will carry a low-grade sense of something being missed or going wrong. This is normal. It does not mean the day is failing.

6. When the urge to check arrives, name it aloud or internally: “That is the urge to check.”

7. Set the urge aside without acting on it. What to expect: The urge will return. Each time you name it and set it down, the interval before the next one tends to lengthen.

Warning: If rest feels like waste through the third or fourth hour, that is not evidence the practice is broken. Discomfort this early is the cost of entry, not a reason to stop.

8. Spend the remaining hours in ways that do not produce output. Walk somewhere. Read without purpose. Eat without a screen. Let time pass without measuring it.

9. The following morning, return to work as normal. What to expect: The day after a kept rest day tends to return a quality of attention that was absent the week before. Problems that felt stuck sometimes resolve without deliberate effort. This is what a rested mind does; it is not surprising once you have seen it happen a few times.

10. Repeat on the same day the following week.

You have now kept a day of rest. The practice builds across months, not across one attempt, and the week eventually reorganizes around it rather than losing a day to it.

Marking a long-serving colleague's departure

Mark Howard’s departure in a way that makes what he carried visible.

Before you begin:

• Reserve sixty to ninety minutes in a room with the people who worked closest to him
• Locate the incident report from the Saturday he resolved the production outage alone, three years before the most recent reorganization
• Ask his three mentees to come prepared with one specific thing he said or showed them that they still use today

---

1. Open by stating the purpose in one sentence: you are here to mark what twenty-six years in one role actually contains, not to read a list of job titles.

2. Read the Saturday incident report aloud.

   Expected outcome: At least two people in the room will not have known he handled it alone. Wait ten seconds before moving to the next step.

3. Ask each mentee to name their one thing. Take them in order; do not comment between them.

4. Write each contribution on the whiteboard as it is named, in the mentee’s own phrasing.

5. Ask Howard to name the project that came closest to failing and the single decision that kept it on track.

   Note: Do not move to the next step until he finishes. Cutting this short loses the only version of this story that exists.

6. Ask the room which of the things on the whiteboard will move to someone here when Howard leaves, and which have no clear owner.

7. Write the answers in two columns: “Owner identified” and “Owner needed.”

Warning before step 8: Howard will almost certainly redirect credit to the team. Let him finish. Then ask the team directly what he contributed that they could not have supplied themselves.

8. Give Howard the floor for as long as he needs. Set no time limit and hold no agenda item after this one.

Confirmation: The departure is marked when everyone in the room can name something specific Howard did or said that shaped them, and when at least one item in the “Owner needed” column has been claimed.

Marking the team shipping a hard, long project

Rebuild the Meridian checkout flow from scratch, with the old system running in parallel the entire time, to eliminate a chronic cart-abandonment problem.

Before starting

• A documented baseline of cart abandonment, shared and agreed on by the team
• A commitment to run two systems in production simultaneously throughout the project
• A team prepared to carry that overhead for however long the rebuild requires

Steps

1. Map every failure path in the existing flow and document what triggers abandonment.

2. Stand up the new checkout service behind a feature flag with no customer-facing exposure.

3. Warning: a schema mismatch at this stage creates silent payment failures that are difficult to trace later. Migrate the first payment integration and verify every field mapping before routing any traffic.

   Outcome: the integration connects cleanly.

4. Route a small, controlled percentage of live traffic to the new flow.

   Outcome: the routing holds and the team receives the first real-world signal with limited exposure.

5. Pause routing and investigate the first critical incident.

   The new flow accepted a payment but dropped the order confirmation event. The legacy system caught it, but the team had forty minutes of uncertainty about whether orders were lost. Kenji Okafor and Dara Reiss traced the bug overnight and by morning had isolated the event-emission failure. They added a pre-flight validation gate before routing could resume.

   Outcome: one new check inserted before step 4 on all future routing attempts.

6. Run a full load test before the next scheduled launch date.

   Outcome: the test finds a session-store connection limit at roughly two hundred concurrent carts. The launch date slips.

7. Rewrite the session-handling layer.

8. Rerun the load test and confirm it clears the revised capacity threshold.

   Outcome: it passes. Soo Anand made the call to slip the launch date rather than proceed on an unverified fix - this is what that decision bought.

9. Brief the wider organization on the revised timeline.

10. Warning: the first hour under full production load is where any remaining failure will surface. Assign someone to monitor alert thresholds manually until patterns stabilize. Execute the full traffic cutover during peak load.

    Outcome: the flow holds. Cart-abandonment rates fall from baseline. No rollback is initiated.

11. Decommission the legacy checkout service.

    Outcome: the parallel system is gone. The original problem is measurably smaller.

The Meridian checkout team completed the task fourteen months after it started.

Arguing a public position on return-to-office

This guide walks your team through adopting a deliberate hybrid model with shared anchor days.

Before you begin

• A leadership team willing to commit the policy in writing, not only in a presentation
• A working list of roles that require on-site presence for compliance or physical-safety reasons (those are managed separately and are out of scope)
• Honest acknowledgment from all sides that neither full return to office nor permanent fully-remote has landed cleanly for most teams

Steps

1. State the actual goal before anything else.

   Write one sentence at the top of a shared document: the goal is a work model that sustains trust, collaboration, access to talent, and individual focus at the same time. Not “where people sit.”

2. Audit which activities genuinely require in-person presence.

   Go through recent calendars and meeting histories. Mark each recurring activity “requires in-person,” “remote adequate,” or “either.” Decide by activity, not assumption.

   Expected outcome: a list shorter than office-first leaders predicted and longer than fully-remote advocates expected.

3. Choose your anchor days.

   From the step 2 list, identify two or three days per month where in-person activities naturally cluster. These become the anchor days: firm, shared, on site for everyone.

   Warning: Anchor days must be real commitments, not suggestions. A soft anchor collapses into a random-presence office within a quarter - worse than either end of the spectrum because it combines commute friction with remote disconnection without delivering either benefit.

4. Declare the remaining time explicitly flexible.

   Write “all other days are the employee’s choice” in the policy document. Implicit flexibility becomes a permission that managers must re-grant each time they feel like it. That is not flexibility.

5. Address the office-first objection before someone else does.

   Write it into the document: “serendipitous hallway conversation drives our best ideas.” Then answer it: two days of genuine presence outperform five days of grudging presence. The trust built on anchor days carries across the weeks in between.

6. Address the fully-remote objection before someone else does.

   Write it in: “anchor days are return-to-office with extra steps.” Then answer it: a clearly bounded, published requirement is qualitatively different from an open-ended “we expect people in most of the time” norm that nobody ever defined.

7. Circulate the draft to three people who will disagree with it.

   Specifically: your most office-committed leader, your most remote-committed employee, and someone who joined in the last six months. Their objections will show which answers in steps 5 and 6 need more work.

8. Publish the final policy with a date, an owner, and a scheduled review.

   A policy document without a review date becomes permanent by neglect. Set the review at twelve months out.

Your team now has a deliberate hybrid policy - clear on the shared commitment, explicit about individual flexibility, written down, and owned.

Announcing a new product to an outside audience

This guide walks you through your first Tidemark session - from a pile of raw customer feedback to a ranked, shareable roadmap your team can act on. Tidemark is a new tool for small teams that replaces the usual triage process: copy-paste into a spreadsheet, argue about priority in a thread, repeat. It opens to the public on Wednesday, July 8.

Before you begin

• Identify where your current customer feedback lives: support inboxes, chat logs, survey responses, or notes from customer calls
• Choose one source to start with - your most recent batch works best for a first run
• Have a work email address ready for account setup

Steps

1. Go to tidemark.io and click “Request early access.” Expected: A confirmation email arrives within a few minutes.
2. Open the email and click the verification link. Expected: You arrive at the Tidemark dashboard with an empty workspace.
3. Click “Import feedback” in the top navigation bar.
4. Paste text from your chosen source into the import field. Do not clean, tag, or restructure the text first. Tidemark handles unformatted input.
5. Click “Extract items.” Expected: Tidemark parses the text and lists each distinct customer request as a separate row in the left panel, with a rough category label on each. A batch of 50 support emails typically produces 30 to 80 distinct items.
6. Scan the extracted list and remove any duplicates or off-topic rows.
7. Click “Rank.” Expected: The list reorders automatically. Items that appeared more often and were expressed with more urgency rise to the top. This is a starting point for your judgment, not a final answer.
8. Drag items to adjust the ranking where your team’s context should override the automated score.
9. Click “Share roadmap.” Expected: A dialog appears with a shareable link. Anyone with the link can view the ranked list in read-only mode without signing in. The link does not expire.
10. Copy the link and send it to your team or stakeholders.

Your team now has a single ranked roadmap instead of a thread full of competing opinions.

A personal year-end reckoning with a difficult year

This is how to close out a year that broke in two places and did not repair itself.

Before you begin

• Your notes from the Clearwater project, or whatever record you kept. If you kept none, you will be working from memory, which is less reliable than you think.
• A clear-headed recollection of how things stand now with Rena. You do not need to have made sense of it. You need to be willing to name it accurately.
• Understand that this procedure does not produce resolution. It produces an honest account. Those are not the same thing, and the difference matters.

1. Write the Clearwater project’s stated goal at the top of a blank page. Not what the work might eventually have become. The goal you committed to before the first deliverable.

   The gap between that line and what was actually delivered is the full size of what you are reckoning with. Do not minimize it yet.

2. Write one sentence describing what the project produced instead. Subject, verb, object. No adverbs.

3. List the three decisions you made on the project that you would make differently. Yours only - not the client’s, not the team lead’s.

   If you find yourself writing someone else’s decisions, delete them and begin the list again.

4. On a new page, write Rena’s name. Below it, write one sentence describing what the relationship was before September, and one sentence describing what it is now.

   The difficulty of writing the second sentence will be proportional to how much the relationship mattered to you.

Warning: The following step produces information about what you actually believe you did wrong, not what is comfortable to acknowledge. Complete it regardless.

5. For each thing you got wrong this year, write a sentence beginning with “I would” rather than “I wish.” Active voice, no conditionals.

6. Decide what you are carrying forward into the next year. Choose one thing only.

   Choosing three is a way of choosing none.

7. Stop.

The account is complete.

Appears in diff-pairs

• procedural vs diataxis-explanation (varies style)
• procedural vs question-and-answer (varies style)
• procedural vs narrative-case-study (varies style)