Tweet Thread
A sequence of numbered short posts (1/, 2/, 3/…) each under 280 characters, telling one connected story or making one connected argument across the chain.
Tweet Thread
Section titled “Tweet Thread”A tweet thread is a chain of short posts (commonly 5 to 25) where each post stands on its own and also pulls the reader forward to the next. The lead is the hook; the middle carries the substance, one beat per tweet; the close lands the takeaway. The hard 280-character budget per post forces tight prose: no warm-up sentences, no transitions, no asides. Every tweet has to earn its position.
Canonical template
Section titled “Canonical template”1/ [Hook tweet - works as a standalone post; promises a payoff; under 280 chars]
2/ [Set up the problem or the question - one beat, one idea]
3/ [First main point or first piece of evidence]
4/ [Second main point or example - keep momentum]
5/ [Turn, twist, or surprising detail - the moment that justifies the thread]
6/ [Synthesis or implication]
7/ [Closing takeaway - the line you want quoted back at you]
8/ [Optional CTA: link to longer piece, follow, retweet if useful]When to use
Section titled “When to use”Use a tweet thread for public commentary where reach matters, for distilling a longer piece into a shareable summary, for live commentary on an event, or for building an audience around a topic over time. The format is at its best when you have one clear argument or one clear story that can survive being chopped into discrete beats.
When not to use
Section titled “When not to use”Do not use a thread for private team communication (use slack-message). Do not use it for long-form essays where the argument needs continuous prose (use blog-post-long-form). Do not use it for anything emotionally complex that will collapse under 280-char compression. Do not use it for formal or authoritative communication.
Pairs well with
Section titled “Pairs well with”columnist, playful, candid
Often confused with
Section titled “Often confused with”slack-message: Both are short async digital messages, but a Slack message is private team communication inside a channel, while a tweet thread is public broadcast to a general audience. The voice, the stakes, and the conventions are completely different - Slack rewards being scannable to teammates; threads reward being quotable to strangers.
Instruction
Section titled “Instruction”Write a tweet thread of [N] numbered tweets, each under 280 characters. The lead tweet must workas a standalone post and promise a payoff strong enough to make a curious reader open the thread.Each subsequent tweet should carry one idea, one beat, or one example - do not slice a paragraphacross tweets. Use line breaks generously; white space is part of the format. The closing tweetshould land the takeaway in a quotable line. Optionally add a final CTA tweet with a link orfollow ask. Voice should match the platform: candid, confident, occasionally playful. Avoidcorporate-speak; the thread format rewards plain language and direct opinion.Template
Section titled “Template”See the Tweet Thread template.
Related
Section titled “Related”Pairs well with
Section titled “Pairs well with”Avoid with
Section titled “Avoid with”Often confused with
Section titled “Often confused with”Examples
Section titled “Examples”1/ We killed our daily standup six months ago. 11 engineers, 4 timezones. Here is what happened, and what I would tell another EM thinking about it.
2/ The math that broke us: 9am Pacific standup = 9:30pm IST. Our India team attended 3.2 out of 5 days. Our US team showed up 4.6. We were running two different teams pretending to be one.
3/ The 14-minute meeting produced about 4 minutes of signal. The rest was round-robin throat-clearing. And none of it persisted. By Wednesday, nobody remembered what Monday’s standup covered.
4/ The replacement: post in #team-standup before 10am local. Three fields. Shipped. In progress. Blocked or at risk. If you are blocked, @mention the person who can unblock. That is the entire ritual.
5/ The sync time did not disappear. We banked it into one 60-minute Thursday working session. Real decisions, real design conversations. If there is no agenda by Wednesday, we cancel.
6/ Week 2 numbers: 47/55 posts on time. Median blocker resolution: 18 minutes. India engineers contributed every weekday for the first time ever. Five person-hours per week recovered, net of the Thursday slot.
7/ The thing nobody warns you about: writing is harder than talking. Engineers who breezed through sync standups struggled with the post. That is a feature, not a bug. The async post forces clarity.
8/ What I got wrong: I underestimated the on-call triage load. Reading 11 posts and routing blockers takes 25 minutes some mornings. We are watching whether to rotate this faster.
9/ If you try this: do not half-async it. A daily call plus an async post is just more work. Pick one. We picked async, with a single weekly synchronous slot held for the things async cannot do.
10/ The hardest part is not the process. It is convincing senior leadership that an engineering team without a daily standup is still a team. Show them the blocker resolution times. The data does the arguing.
1/ I spent 30 days running an intentional morning routine instead of a reactive one. Here is what actually changed, what I got wrong, and the one rule that mattered more than the rest combined.
2/ Baseline: wake at 6:30, phone in hand before my feet were on the floor, Slack-shaped by 7, fried by 2pm. I am a working adult with a family and a 9am start. I have finite energy. I was spending it badly.
3/ The protocol: water, light, movement, planning. In that order. No phone until the planning step. 35 minutes that belong to me before the day starts negotiating.
4/ The single rule that did most of the work: phone charges in the kitchen overnight. Not the nightstand. Not “on do not disturb.” In a different room. Distance was the only barrier my willpower respected.
5/ Numbers from month one: 23 of 30 mornings completed. Phone-deferred 28 of 30 mornings. Wake time held at 6:15 on 19 of 30. The failures were instructive, not catastrophic.
6/ The thing I did not expect: writing the top three by hand was the highest-quality planning I have ever done. Something about paper makes the bullshit tasks not survive the trip from brain to pen.
7/ What I got wrong: I assumed the hard part would be waking up. The hard part was Tuesday. Monday consumes the week’s buffer and Tuesday morning arrives with nothing in reserve. I am still working on that one.
8/ The travel problem is real and unsolved. The protocol assumes a familiar environment. Hotels and time changes break it. Month two has a travel variant in design.
9/ If you try this, start with one rule, not four. Phone in another room. Run that alone for two weeks. Add the rest only when the phone rule is automatic. I did all four at once and it nearly didn’t take.
10/ The point was never the routine. The point was getting the first hour back. Once the first hour belongs to me, the rest of the day stops feeling like something that happens to me.
Tweet Thread - Picking a database, 8 tweets
Section titled “Tweet Thread - Picking a database, 8 tweets”1/ We just made a database decision at our 50-person startup that I would have made differently 5 years ago. Postgres or DynamoDB for a new real-time notification service. We picked the boring one. Here is why, and why you probably should too.
2/ Setup: Lattice Notify, 8 backend engineers, 4-person on-call rotation, monolith on Postgres. New service needs to handle 500K events/day at launch, possibly 5M in 12 months. Two engineers, two opposing recommendations, three days to decide.
3/ Marcus (senior eng) made a strong case for DynamoDB. He was right on the technical merits. The access pattern (write-heavy, point lookups by user) is exactly what DynamoDB was built for. If this were the only dimension, the meeting would have lasted 10 minutes.
4/ Ana (tech lead) made the operational case for Postgres. We already run it. The on-call rotation has 3 years of muscle memory with it. There is a runbook for every failure mode we have hit. Adopting DynamoDB doubles the operational surface on a 4-person rotation.
5/ The interesting thing is that this was not a “boring vs exciting” argument. It was a “what can we recover from” argument. Both options are recoverable in 3-6 weeks if we are wrong. The difference is which mistake is more predictable to recover from.
6/ The turn: at 8 backend engineers, your operational capacity is one of your scarcest resources. Spending it to adopt a new database needs to clear a high bar. “Better access-pattern fit” is real, but it is the argument that wins at 80 engineers, not 8.
7/ We picked Postgres. Added a documented revisit threshold (5M events/day sustained) so we are honest about when to ask the question again. Ships to production in 3 weeks. Marcus is fine with it because he agrees the operational argument is load-bearing right now.
8/ The takeaway I want you to carry: when you have a database decision in front of you, do not ask “which one fits the access pattern.” That answer is in a docs page. Ask “which one’s failure mode do we already know how to survive.” Pick the boring database, on purpose.