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.
- A numbered sequence of short posts (1/, 2/, 3/…), commonly 5 to 25
- A lead tweet that works as a standalone hook and promises a payoff
- Each post under 280 characters carrying a single beat: one idea, one example, one turn
- A turn or surprising detail that justifies the thread existing
- A closing tweet that lands a quotable takeaway, often with a CTA
- Generous line breaks - white space is part of the format
Anti-patterns
Section titled “Anti-patterns”- Slicing a paragraph or essay into 280-character pieces - A thread is a sequence of complete thoughts, not a chopped essay; if the argument needs continuous prose it belongs in a blog-post-long-form.
- Treating the thread as private team communication in public - That confuses it with a slack-message; a thread is public broadcast to strangers and rewards being quotable, not scannable to teammates.
- Opening with set-up before the hook - The lead must work alone and earn the click; a warm-up first post is wasted on readers who never open the thread.
Failure modes
Section titled “Failure modes”- Over-hooks every post into engagement-bait - each tweet strains for a cliffhanger or hot take until the thread is all teasers and no substance - Reserve the hook for the lead and let the middle carry real beats; if a post promises a payoff it never delivers, replace the bait with the idea itself.
- Over-compresses past the point of meaning - the 280-char budget is squeezed so hard the beats become cryptic fragments that lose the argument - The budget forces tight prose, not lost meaning; if a beat no longer reads as a complete thought, give it its own tweet rather than cramming it.
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”- Should we adopt async-first standups?
- How to start a morning routine
- How to choose between Postgres and DynamoDB for a new service
- Telling stakeholders a committed feature is being cut this quarter
- Getting a new engineer productive in their first two weeks
- Writing to thank a mentor who shaped your career
- Reflecting on keeping a discipline of rest
- Marking a long-serving colleague's departure
- Marking the team shipping a hard, long project
- Arguing a public position on return-to-office
- Announcing a new product to an outside audience
- A personal year-end reckoning with a difficult year
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.
1/ Insights isn’t shipping in Q3.
That’s not what we planned. It’s not what we told you.
Here’s what happened, what we chose, and what we’re doing before the quarter ends. 🧵
2/ Insights was our Q3 commitment: an in-app analytics dashboard so you could see your data, trend it, and act on it - without leaving the product.
3/ In Q2, a mandatory billing-system migration scope-crept. It had to ship. It consumed most of the engineering capacity we’d set aside for Insights.
4/ Two options on the table:
Ship Q3 - half-built, key charts missing, filtering broken. Ship Q1 - complete, actually useful.
One of those is worth shipping.
5/ Half-built dashboards are a trap. You spend time learning a tool that can’t yet do what you need. Then you stop trusting it. We didn’t want to do that to you.
6/ So Insights moves to Q1. Full scope: the dashboard, filters, data views, trend lines - all of it. That’s the version we committed to, and that’s the version we’re building.
7/ Before Q3 ends - in September - we’re shipping a CSV export of the underlying Insights data. Same data, no UI. Pull it into a spreadsheet or BI tool and run your own analysis now.
8/ It’s not the product we owe you. But you won’t be blocked. The data is clean, the export is real, and you can work with it while we build the right home for it.
9/ We told you Q3. We’re not delivering Q3. That’s on us.
What we can control: something useful in your hands this quarter, and Insights done right in Q1.
10/ Sales team: use this to set expectations with your accounts. Key customers: reach out. We want to hear what you need most before we lock Q1 specs.
1/ Priya started Monday. Daily-deploy backend. On-call rotation starting week three. Two weeks to her first real shipped change. Here is what we did - and what most teams quietly skip.
2/ Most onboarding: “here’s the wiki, good luck.” Then surprise when the new hire is still lost in week four. The gap is never the wiki. It’s the three things the wiki doesn’t say.
3/ Day 1 goal: one working thing. Not everything configured. Not the full codebase. One service up, one call succeeding in local dev. She needs a small win to build on, not a full picture to drown in.
4/ Day 2-3: the codebase tour is not a lecture. We walked the request path of the noisiest service together - request in, response out, who owns what along the way. She asked questions at every step.
5/ Pairing on day 3 surfaced the thing the wiki never says: where config actually lives. Not the file. The channel. Not the channel. Someone’s head. We documented it on the spot.
6/ Week 1 priority order:
- Access (she can do things)
- Context (she knows why things are the way they are)
- Belonging (she has a seat at the table)
Most teams stop after access. Belonging is almost never planned.
7/ Here is the thing most onboarding gets wrong: the first PR tells her exactly what kind of team she joined. I reviewed it the same way I review anyone’s. Real feedback. No grade inflation.
8/ She shipped a real change Thursday of week two. Not a toy. Not a tutorial. A fix in the service she’d spent a week in. The PR was good because she understood the code, not because we made it easy.
9/ What we never say out loud but have to: “this is yours now.” She needed to own one runbook section, one service area, something concrete. You can’t belong if you never own anything.
10/ By end of week two: one change shipped, on-call shadow done, one service she knows cold, and - the part that takes longest to build - she knows who to call when something breaks at 2am.
11/ Functioning in two weeks is the floor. Feeling like she was supposed to be here - that is the ceiling we were actually aiming for. Plan for both or you will only hit one.
12/ If you are onboarding someone on a team that ships daily: Slow is fast. One working thing per day beats a firehose of context. People who feel lost don’t catch up. They leave.
1/ Last week I handed a project to someone who wasn’t ready for it.
As I watched her find her footing, I felt something familiar.
I’ve been here before. On the other side.
Thread: what Dana taught me about the best thing a mentor can do.
2/ Ten years ago, Dana was my manager.
I was 18 months into my career.
She told me I was going to lead the next client rollout.
I told her I wasn’t ready.
She said: “I know. That’s why I’m asking you.”
3/ The project was a mess for two months.
I made every mistake you could make early.
Dana watched. She didn’t step in.
She let me own it - every failure, every scramble, every salvage.
4/ What she did do: showed up every week.
Not to review my work. To ask what I was learning.
That question changed the texture of the whole thing.
I stopped seeing setbacks as failures. I started filing them.
5/ There’s a thing I didn’t understand until last week.
Dana had the credibility to step in at any point. Her name was on the account too.
Staying out of it wasn’t neutral.
It cost her something.
6/ What it made possible: I led the next three projects without asking permission.
Not because I stopped being nervous.
Because I’d already proven to myself that nervous and capable can be the same thing.
7/ Last week, watching my direct report figure out her own version of the scramble - I heard Dana’s voice.
“What are you learning?”
I didn’t say it out loud. I didn’t have to. I just stopped myself from stepping in.
8/ The best mentors don’t transfer their confidence to you.
They engineer the conditions where you find your own.
Dana did that.
It took ten years to understand what that actually cost her to give.
9/ If you have a Dana in your past: tell them.
Not with a vague “thanks for everything.”
With the specific thing they did. And what it cost them. And what it opened.
1/ I took a full day off from work last week.
No phone. No notifications. No “just one quick check.”
I’ve tried this before and always broke by noon.
This time something was different.
2/ The problem isn’t willpower.
It’s that the urge to check one more thing feels productive. It feels like care.
Stopping feels like falling behind.
3/ I’ve told myself I’d rest on Sundays for years.
What I actually did was work slower and feel guilty about it.
There’s a difference.
4/ The first few hours of a real rest day feel wrong.
Not relaxing. Wrong.
Like I’m forgetting something. Like I should be somewhere. Like time is being wasted.
5/ That anxious feeling is data.
It means my whole self has been organized around output. Around proving, through motion, that the day was worth something.
Rest says: it’s already worth something.
6/ By afternoon it gets quieter.
Not productive-quiet. Just quiet.
My thoughts stop sprinting. They start moving like people walking somewhere they actually want to go.
7/ Here’s the thing I didn’t expect:
The day doesn’t disappear from the week. It reorganizes it.
Monday comes back sharper. The work I thought I was “missing” waits, and it’s easier when I get there.
8/ Rest has a cost.
One day a week where you don’t earn anything. Don’t finish anything. Can’t point to anything and say: I did that.
For someone used to measuring days by output, this is not small.
9/ But rest also returns something.
Not productivity. Not even energy, exactly.
Steadiness. A sense that the week belongs to a person, not to a task list.
10/ What I’ve learned: rest isn’t the absence of work.
It’s a different kind of claim.
A claim that you are not only what you produce.
That you are allowed to exist on a day where nothing gets done.
11/ If you’ve tried this and failed - you’re not lazy.
You’re just someone whose entire identity got braided into output.
Untangling that takes more than good intentions. It takes practice.
12/ One more thing:
The anxiety at the start of a rest day is not proof the rest isn’t working.
It’s proof you needed it.
1/ Howard retires today after 26 years.
He never made VP. He never asked to.
He was something harder to replace.
A thread.
2/ His title didn’t change in two decades. Same desk, same team, same work.
While the org chart reshuffled around him, Howard became the org chart that actually mattered.
3/ You know the person people call when a project is on fire?
When the client is furious and the system is down and nobody can remember why we built it that way?
That was Howard.
4/ He didn’t put it out dramatically. He’d find a file, make a call, say “here’s what we did in 2019” - and the crisis would quietly stop being a crisis.
No announcement. No credit.
5/ Three people sent notes this week saying “Howard is the reason I stayed.”
Not the reason they got promoted. The reason they didn’t quit.
6/ He never ran a formal mentoring program. He just answered questions. Remembered what you told him last month. Showed up when something went sideways.
That’s the whole system.
7/ The notebook.
Color-coded tabs. Decades of decisions in there. Every post-mortem, every vendor call, every “here’s why we don’t do it that way.”
No one else has that.
8/ Here’s the detail that tells you everything:
He turned down a management role twice. Said he was “more useful here.”
For 26 years, he was right.
9/ What his absence actually costs:
Somewhere in the next six months, a junior person hits a problem Howard would have solved in ten minutes. They won’t know who to call.
That’s the real gap.
10/ We’ll write down what we can. Build documentation. Try.
But institutional memory lives in a person - in their judgment, in knowing not just what happened but why.
You can’t export that to a folder.
11/ Howard proved something most orgs don’t reward:
Staying is a choice. Depth is a skill. Being the person everyone trusts takes twenty years and looks invisible from the outside.
26 years. Same desk. Irreplaceable.
12/ Happy retirement, Howard.
Thank you for 26 years of quietly keeping the rest of us from making the same mistake twice.
1/ 14 months. Two near-misses. A launch that slipped twice. And today, a checkout rebuild that held under peak load without a single rollback.
A thread on what this team actually did.
2/ Our checkout had a chronic cart-abandonment problem. Not a crisis. Just a slow, steady leak, quarter after quarter. The code had grown too tangled to safely touch. The fix required a full rebuild.
3/ Priya’s team made a hard call: rebuild from zero, but keep the old system live the whole time. Migrate users in batches. Clean in theory. Brutal in practice.
4/ For 14 months, they ran two production checkout systems simultaneously. Every deploy touched both. Every bug in one risked a mirror in the other. No exit until the migration was done.
5/ Near-miss one. Marcus caught a data-consistency issue two hours before go-live. He could have flagged it and let someone else make the call. Instead he stopped it himself. Launch slipped six weeks.
6/ Near-miss two. Load-test results were marginal. Pressure from above to just ship. Keiko pushed back, ran the tests again, and found the ceiling. Three more weeks. Nobody thanked her in the moment.
7/ Here is the thing: the launch slipping twice is why the final rollout held. You do not get a clean ship by ignoring what could break it. Those delays were not failures. They were the project.
8/ Rollout week. Peak load. Real traffic. The new system held. No incident. No rollback. For a team that had lived inside two codebases for over a year, it ended very quietly.
9/ Month eleven, three engineers were close to the wall. Nadia and Dev quietly redistributed the load - no announcement, no crisis meeting. The team made it to the end without losing anyone.
10/ This is the kind of work that does not look impressive from outside. No dramatic moment, no breakthrough announcement. Just a long, careful effort that cost the team enormously to sustain.
11/ To Priya and everyone on the rebuild: you kept the old system alive, built a new one beside it, and shipped it clean. That is exactly as hard as it sounds. It counts.
12/ Not every milestone looks like a breakthrough. Some of them look like a system quietly holding under peak load after fourteen months of not cutting corners. This is one of those.
13/ If your team has a Marcus, a Keiko, a Nadia - name them publicly today. The invisible hard calls are still calls. Repost if this resonates.
1/ Hot take: the return-to-office debate is being argued at the wrong level.
It’s not “remote vs. office.” It’s “what actually needs presence, and what doesn’t?”
A thread on why I’m backing anchor days.
2/ Companies pushing full RTO often aren’t doing it for collaboration.
They’re doing it because they’re paying for office space and want to see it used.
That’s a real estate decision dressed up as a culture argument.
3/ But I want to steelman the office-first view before I argue against it.
In-person time builds trust faster. Unplanned hallway conversations surface problems that never get filed in a ticket. New hires see how work actually happens.
These are real.
4/ And the fully-remote side has equally real points.
Remote widens the talent pool when geography isn’t a filter. It returns commute hours - hours people use for rest, family, and focus.
Deep work suffers in open offices.
5/ So here’s the question both sides are dodging: what work actually needs presence?
Not “office = culture.” Not “remote = freedom.”
Which specific activities get worse when no one is in the room together?
6/ My answer: anchor days.
Pick 2-3 shared days per month and design them around the work that genuinely benefits from presence - planning, retrospectives, onboarding, hard conversations.
Everything else: wherever you do your best work.
7/ I hear the objection: “You’ll still lose spontaneous collaboration.”
Fair. But I’ve never had a genuinely spontaneous insight at a mandatory standup.
The best unplanned conversations happen when people want to be there, not when they’re required to be.
8/ Next objection: “Culture doesn’t survive without the office.”
Culture is built in moments of honesty, trust, and shared difficulty - not physical proximity.
What kills culture is treating presence as a proxy for engagement. It isn’t.
9/ Last objection: “Anchor days become mandatory attendance with better PR.”
True risk. But it depends on execution. Fill anchor days with work that belongs in the room and people show up motivated.
Fill them with all-hands you could have emailed: that’s the problem to solve.
10/ The honest admission: anchor days are harder to run than either full remote or full office.
You have to consciously decide what belongs in the room. You can’t coast on “everyone’s here anyway.”
That’s not a weakness. That’s the discipline the model demands.
11/ We don’t have a remote-work problem.
We have a “presence-equals-engagement” problem.
Anchor days don’t solve everything. They force the question that actually matters: what does this team need from time together?
12/ If this framing is useful, pass it to whoever’s writing your remote policy.
And if you think I’ve got this wrong, reply. I’d rather debate it in public than pretend the tradeoffs don’t exist.
1/
We built something small teams have been asking for for years.
A tool that takes scattered customer feedback and turns it into a ranked, shareable roadmap.
It’s called Tidemark. It launches next week.
2/
Here’s the problem we kept seeing:
Teams collect feedback everywhere - support tickets, chat messages, sales calls, survey forms.
But it never gets synthesized. It sits in silos.
Nobody can see the whole picture.
3/
The result?
Decisions made on whoever shouted loudest.
Not what customers actually needed. Just what someone remembered from the last big account call.
4/
Tidemark pulls all of that feedback into one place.
It clusters by theme.
It scores each cluster by frequency and signal strength.
You get a ranked list of what your customers actually want.
5/
No algorithm deciding what you should build.
Just your own feedback, organized so you can finally see it clearly.
The ranking is yours to adjust. You own the output.
6/
Here’s what surprised us in testing:
The ranked list isn’t just useful internally.
It changes how you talk to customers.
“Here’s why we built X before Y” is a real conversation when you have the receipts.
7/
Small teams have been solving this with spreadsheets and sticky notes. Nothing wrong with that.
But Tidemark gives you a shareable link instead of a chaotic file.
Your whole team sees the same roadmap.
8/
Roadmap decisions are political inside most teams.
They don’t have to be.
When everyone can see the ranked feedback, the conversation moves from “I think” to “the data says.”
That changes the room.
9/
The best roadmap isn’t the one the loudest person in the room built.
It’s the one your customers built. You just had to collect it, rank it, and share it.
That’s what Tidemark does.
10/
We’re launching next week.
If your team is drowning in feedback with no clear picture of what to build next - Tidemark is for you.
Try it free at launch. Link in replies.
1/ This year tried to take me apart. It mostly succeeded.
A thread on what actually happened, and no tidy ending at the bottom of it.
2/ The project I’d spent two years building fell apart in March.
Not dramatically. It just stopped working. The outcome I’d needed didn’t come. I had to call it.
3/ I made some of that failure myself. I held on too long because I’d poured myself into it.
Sunk cost dressed up as conviction. I’m still learning to see the difference in real time.
4/ Around the same time, a relationship I’d trusted started shifting.
Not a fight. Not a rupture. A slow divergence I only noticed after it had already happened.
5/ I tried to fix it. Had the conversations. Laid it all out and asked them to meet me there.
They couldn’t. Not because they’re a bad person. It’s just where we ended up.
6/ Here’s the part no one tells you: two losses at once don’t feel like two losses.
They feel like a verdict. Like the year is trying to tell you something about who you are.
7/ Grief without permission is strange.
Neither of these was a death, so no one brought food. I still had to be functional. Answer emails. Show up. The inside and outside were very different.
8/ What I got wrong: I thought grinding through it was the same as processing it.
It isn’t. You can perform fine for months and still be completely underwater. I found that out the hard way.
9/ I kept waiting for the year to develop a shape. For it to resolve into a lesson I could name.
It hasn’t. I’m ending this year more uncertain than I started it. That used to frighten me more.
10/ Some things I’m choosing to carry forward:
The knowledge that I can take a hit and keep going. That’s not the same as thriving. But it’s not nothing.
11/ Some things I’m leaving behind:
The version of me who believed that caring harder and working longer meant outcomes would bend. That was a beautiful lie. I’m done with it.
12/ A hard year doesn’t become a good year in retrospect.
Sometimes it just stays hard. You carry it differently. That’s the most honest thing I have.
Appears in diff-pairs
Section titled “Appears in diff-pairs”- tweet-thread vs slack-message (varies format)