Slack Message
A short, async-first message designed for team channels - direct, scannable, and respectful of the reader’s attention in a high-volume feed.
Slack Message
Section titled “Slack Message”A Slack message in a professional context competes with dozens of others in the same channel. The reader skims. The effective Slack message acknowledges this and works with it rather than against it: the most important information appears in the first line, the message is short enough to read without scrolling, and any required action is explicit.
Canonical template
Section titled “Canonical template”[One-line summary - the message should be understandable from this alone]
[Optional: 2-4 bullet points for supporting detail]
[Optional: @mention for required action][Optional: thread invitation for discussion]When to use
Section titled “When to use”Team status updates, quick questions, sharing a link with context, incident notifications, async decisions.
When not to use
Section titled “When not to use”Formal communication requiring a paper trail, communication with external parties, emotionally complex topics that deserve more space.
Pairs well with
Section titled “Pairs well with”operator, friendly-mentor, matter-of-fact, candid, warm
Often confused with
Section titled “Often confused with”prd: A PRD is a structured multi-section document defining product requirements. A Slack message is a short async communication in a team feed - the two should not be confused in practice, but “format” as a category occasionally causes library navigation confusion.
adr: An ADR is a permanent record of an architectural decision. A Slack message is ephemeral async communication - it may contain a decision, but it is not a record of one.
Instruction
Section titled “Instruction”Write as a Slack message for a professional team channel. Lead with the most importantinformation in the first line - the message should be understandable from the first line alone.Keep it short enough to read without scrolling. If the message is complex, use bullet points tomake it scannable. Make any required action explicit and specific: "@alex can you confirm byEOD?" not "let me know what you think." Match the channel's tone - standup channels are moreformal, social channels are warmer. Respect the reader's attention in a high-volume feed.Template
Section titled “Template”See the Slack Message template.
Related
Section titled “Related”Pairs well with
Section titled “Pairs well with”Operator, Friendly Mentor, Matter of Fact, Candid, Warm
Avoid with
Section titled “Avoid with”Often confused with
Section titled “Often confused with”Product Requirements Document, Architecture Decision Record
Examples
Section titled “Examples”Proposal: try async standups for 30 days starting May 19
Our 9am standup is hard on the India team and the info disappears after each call. Want to run an experiment:
- Each person posts to #team-standup by 10am local time (3 fields: shipped / in progress / blocked)
- Blocked items @mention the person who can unblock
- On-call reads the channel by 9am PT and responds to blocks within 30 min
- We keep Thursday 3pm as a real working session for anything that needs live discussion
@priya @arjun @deepa - this gets you out of 9:30pm standups. Want to hear your reaction first.
:thread: Drop thoughts in thread by Friday and I will send a final plan Monday.
#productivity-experiments
Week 5 update on the no-phone-first-hour experiment - it is actually working :raised_hands:
The setup:
- Phone stays in the kitchen until 7:30am
- 6:30 wake -> water, 10 min outside for light, 15 min walk, 10 min paper planning
- No app, no tracker, just a notebook
Adherence so far: 26/35 weekdays. The misses were mostly travel or sick days. Surprising thing: the calm part is real but the bigger win is showing up to my 9am block already knowing what I want to do.
Happy to share the (very boring) notebook template if anyone wants it. Reply in thread and I will DM.
cc @sarah-r @marcus-d - you both asked about this last month
Slack message - #notify-arch channel
Section titled “Slack message - #notify-arch channel”Posted by Ana, 2026-05-14 4:18pm
Recommending Postgres for the notification service. Need sign-off from Marcus and Priya by EOD Thursday so we can lock at Friday 11am and plan the sprint at 2pm.
- Both options handle 500K events/day at launch. DynamoDB fits the access pattern better; Postgres fits our 4-person on-call rotation better.
- Adding a second datastore at 8 backend engineers is the load-bearing concern. Marcus and I aligned on this last night.
- Revisit threshold: 5M events/day sustained (covers the 10x Slack-deal scenario with ~3 months warning).
- Full reasoning in ADR-0023 draft: https://wiki.latticenotify.com/adr/0023
@marcus please confirm the revisit threshold language works for you. @priya please confirm the 11am Friday sync is locked. Thread for discussion.