Blog Post (Long Form)

A substantial web article of 1,500-3,000 words - long enough to go deep, short enough to respect the reader’s time.

Blog Post (Long Form)

Long-form blog posts occupy a specific territory: they go deeper than a quick take but stop before they become a whitepaper or essay. The format works because it has a conversational quality that whitepapers lack - the writer is present, the voice is recognizable, and the reader feels addressed rather than briefed.

Structure matters more in long-form than in short-form because the reader needs navigation. Headers every 300-500 words, a clear progression from setup to insight to implication, and an opening that immediately establishes the specific territory.

Canonical template

[Title: specific, not generic]

[Opening: establishes specific argument and stakes - 2-3 paragraphs]

[Section 1 header]
[Content - 300-500 words]

[Section 2 header]
[Content - 300-500 words]

[Section 3 header]
[Content - 300-500 words]

[Closing: landing, not summary - 2-3 paragraphs]

When to use

Thought leadership, technical explainers, opinion pieces, narrative case studies, educational content.

When not to use

Quick updates, operational documentation, formal reports, anything requiring strict citation.

Pairs well with

columnist, friendly-mentor, candid, warm, diataxis-explanation, classical-argument

Often confused with

adr: An ADR is short, structured, and records a specific decision. A long-form blog post is conversational, substantial, and explores a topic for a general audience.

prd: A PRD defines product requirements internally. A long-form blog post communicates ideas externally to a broad audience.

Instruction

Write as a long-form blog post (1,500-3,000 words). Establish the specific argument or question
in the opening - not the topic, the specific angle. Use headers every 300-500 words to give the
reader navigation. The structure should move from setup through insight to implication. The
opening must earn the reader's next 1,500 words immediately. The closing should land - not
summarize. Give the reader something to carry away. Conversational but substantial - present in
voice, deep in content.

Template

See the Blog Post (Long Form) template.

Related

Pairs well with

Columnist, Friendly Mentor, Candid, Warm, Diataxis Explanation, Classical Argument

Avoid with

Operator, Reverent, Pastoral

Often confused with

Architecture Decision Record, Product Requirements Document

Examples

Should we adopt async-first standups?

Your Daily Standup Is Solving the Wrong Problem

Three engineers on your team are joining your 9am standup at 9:30pm their time. They have been doing it for a year. You have noticed they attend less than the US-based engineers. You have probably assumed it is engagement or discipline. It is neither. It is 9:30pm.

The daily standup is one of the most persistent rituals in software development, and one of the most misunderstood. Most teams that run standups believe they are running a coordination meeting. What they are actually running is a presence ritual with some coordination features bolted on. Understanding the difference is what will help you decide whether to change the format - and if you change it, how to do it without breaking what actually matters.

What a Standup Is Actually Doing

The synchronous standup has two functions that are usually bundled together.

The first is status visibility: who is working on what, what is blocked, what dependencies are about to collide. This is the explicit purpose. A well-run standup surfaces blockers early, catches coordination problems before they become delays, and keeps the team’s work visible to everyone on it.

The second is social presence: the daily act of gathering, of being in a shared moment, of saying “I am here and so are you.” This function is rarely named, but it is real. Teams that have daily standups feel different from teams that do not - there is a rhythm, a sense of shared forward motion, that does not come from the status itself but from the daily gathering.

The problem with synchronous standups for distributed teams is that they impose a coordination overhead to serve the presence function - and the coordination function can be served more efficiently with a different tool.

What Async Standups Do Better

An async standup is a structured written update posted to a shared channel. The format that works best is simple: what shipped in the last 24 hours, what is in progress today, what is blocked or at risk. Blocked items include a direct @mention of the person who can help.

Three things happen when you move from synchronous to async that are genuinely better than the meeting.

The information persists. When @priya posts at 8am India time that the auth service is throwing a 401 on a specific endpoint, that post is there when @dan starts his day in California three hours later. The engineer who hits the same 401 at 2pm can search the channel and find Priya’s diagnosis. In a synchronous standup, the same information evaporates after the meeting unless someone wrote it down. Nobody wrote it down.

Blockers reach the right person faster. In a synchronous standup, a blocker reaches the person who can resolve it only if that person attended the meeting and made a note. In an async channel, the @mention sends a direct notification. The blocker routes itself.

Everyone participates on a schedule that fits their life. The India-based engineer posts at 8am their time. The west coast engineer posts at 9am their time. Nobody is joining a meeting at 9:30pm. The team’s work is visible to everyone, and everyone contributed on a schedule that was reasonable for them.

What Async Standups Cannot Replace

Here is where most writing about async standups stops being honest: the social presence function does not transfer.

A written update in a channel is not the same as being in a room together, or even a Zoom call together. The daily standup, whatever its coordination failures, created a shared moment - a daily rhythm of gathering that built team fabric over time. Async channels do not do this. You can build warmth and personality into your posts, but the shared-moment feeling does not survive the format change.

This is the real reason some teams switch to async standups and feel more fragmented three months later. The coordination problem is solved. The presence problem is worse.

The teams that get this right do not choose between synchronous and async. They separate the two functions and handle them with different rituals. The async standup handles coordination - status, blockers, visibility. A weekly working session handles presence - a synchronous meeting that exists explicitly for collaboration and connection, not status reporting.

How to Make the Switch

The structural change is simple. The adoption challenge is getting the team to post consistently and read attentively.

Start with a pinned template in your standup channel. Three fields. Ship it on Monday. Ask for updates by 10am local time. The team lead reads the channel at the start of their day and responds to blocked items within 30 minutes. That commitment to reading and responding is what makes the channel feel alive rather than a place where updates go to be ignored.

The first two weeks will be awkward. Engineers will post and wonder if anyone read it. Some will miss days. Hold the norm firmly and gently: the format only works if everyone participates. At week three, most teams find their rhythm.

The synchronous meeting does not disappear - it transforms. A 60-minute Thursday working session, reserved for discussion that needs real-time exchange. Not a standup. Not status. A session for the work that benefits from being in the room together.

Run it for 30 days before you decide whether it is working. Track blocker resolution time, participation rate, and do a short team survey. If it is not working, you will have data on what to adjust. If it is working, you will know why.

The Thing That Actually Changes

The shift to async standups is not really about format. It is about what you believe a distributed team owes each other.

The synchronous standup says: we owe each other shared presence, daily, at a fixed time, regardless of what that costs people on the edges of the timezone map. The async standup says: we owe each other visible work and honest blockers, on a schedule that respects the fact that we live in different places.

Both are forms of accountability. The question is which form fits the team you actually have - not the co-located team the standup was designed for, but the distributed team that exists now, on four continents, at four different local times.

The ritual that serves that team is not the one you inherited. It is the one you build.

How to start a morning routine

The First Hour Is the Whole Day

For most of the past year, I have been losing the same forty-five minutes every morning, and I did not realize it was a recurring loss. I would wake around 6:30, reach for my phone in the dark, and surface forty-five minutes later with no memory of what I had read but a vague low-grade tightness across the shoulders. The day had begun without me. Or rather, the day had begun in a register I did not choose, and the rest of it was spent trying to climb back into a register I did.

This is not a productivity essay. There is enough of those. This is a small report from someone who tried, finally, to design the first hour deliberately, and who is now five weeks into the experiment and willing to say something modest about what changed.

What I tried to fix

The problem was not really “phone use.” The problem was the absence of a default. When I wake up, my brain wants a thing to do. It does not particularly care what the thing is. For years the default was “check Slack,” because Slack was within arm’s reach and the act of checking gave me a sense, however illusory, that I had begun.

You cannot remove a default. You can only replace it. This was the part I had been getting wrong.

The four modules

I settled on four small things to do between 6:30 and 7:30am, in this order:

1. Water. Eight ounces, room temperature, before anything else. The point is less hydration than ritual. The first physical action of the day is one I chose.

2. Light. Ten minutes outside, or if the weather is hostile, next to the biggest window in the house. This one has the most published science behind it and the least immediate emotional payoff. I do it anyway.

3. Movement. Fifteen minutes. A walk, some stretching, occasionally bodyweight squats and pushups if the legs feel willing. Nothing that requires changing clothes twice or that I would post to Strava.

4. Planning. Ten minutes with a paper notebook. Three lines: what matters today, what I will protect, what I will let drop.

Total time: roughly forty-five minutes. The phone, meanwhile, sits in the kitchen, plugged in, face down. It is allowed to come back into my hand at 7:30am, when the family wakes and the day formally starts.

The phone is not the enemy. The phone is a vacuum cleaner. If you do not give your morning something to be, the phone will gladly take the empty space.

What I expected

I expected to feel calmer. I expected to be more productive at work. I expected, on some level, that the routine would be the kind of thing I could turn into a small lifestyle brand if it went well.

What actually happened

The calm came, but it came differently than I had imagined. It was not that the mornings themselves became serene. Some of them are still chaotic, particularly the ones when a child wakes up early and the choreography collapses. The change is subtler. The change is that on a chaotic morning I now have something to return to. The routine is a baseline, and a baseline is what I had been missing.

Productivity at work is harder to evaluate. I think I am better. My colleagues have not commented, which is either a sign of nothing or a sign that I had been overestimating how visible my fatigue was to anyone else.

The lifestyle brand fantasy has dissolved entirely, which I count as a victory. The routine got smaller and more boring as it took hold. It is mine now in a way that does not require an audience.

A note on failure

I have missed nine mornings out of thirty-five. Twice I was traveling. Three times I was sick or a child was sick. The other four were just failure - mornings when I woke up, reached for the phone anyway, and was halfway through the email queue before I remembered the design. The routine does not punish me on those days. I just start the next morning at the beginning. The fact that there is a “beginning” to start at, and not a vague aspiration to feel better, is most of the gift.

If you want to try this

You probably do not need my four modules. You need any four modules, chosen by you, that you can stand the sight of at 6:30am. The order matters less than the existence of an order. The content matters less than the fact that you wrote it down before you needed it.

Pick a start date. Move the phone to a different room tonight. Set out the notebook. Tomorrow, when your hand reaches for the device that is no longer there, it will find the glass of water instead. That is the entire trick.

The first hour is not separate from the rest of the day. It is the rest of the day, in miniature, rehearsing.

How to choose between Postgres and DynamoDB for a new service

Why We Picked the Boring Database (Again)

There is a particular meeting that recurs at every growing startup. A new service needs a new datastore. Two engineers, both right in their own way, arrive with opposing recommendations. The PM wants a decision by Friday. The tech lead leans toward the thing the team already knows. The senior engineer leans toward the thing that fits the access pattern. Everyone in the room has read the same blog posts. Nobody has the answer.

We just had that meeting at Lattice Notify. The new thing was our real-time notification system. The two candidates were Postgres (which already runs our monolith) and DynamoDB (which our senior engineer Marcus, with some justification, called “the obvious choice for this access pattern”). The decision was due in three days. I want to write about how we made it, because I think the way we made it is more useful than the answer we landed on.

The actual question is not the question

The framing on Monday was “Postgres or DynamoDB for the notification service.” That is not the actual question. The actual question, once you sit with it for an hour, is something like: which of these two options has a smaller blast radius if we are wrong, given the team we have, the growth we expect, and the time we have to recover?

Marcus is right that DynamoDB fits the access pattern. We are writing 500K notification events per day at launch, with potential for 5M if the Slack-partnership deal lands. The reads are mostly point lookups by user. This is exactly what DynamoDB was designed for. If we were a team of 80 engineers picking from a clean slate, this would be a one-meeting decision.

We are not that team. We are 8 backend engineers with a 4-person on-call rotation, one production database we know how to operate, and a monolith that the new service will need to query. Ana, our tech lead, has been operating Postgres at our scale for three years and has a runbook in her head for every failure mode we have hit. Marcus has read the DynamoDB docs and built one personal project on it. The team is asymmetric on this dimension by a factor of ten.

The actual question is whether the access-pattern fit advantage of DynamoDB is larger than the operational capacity disadvantage of adopting it. And the only honest answer is: probably not, but we have to think about it carefully, because the cost of getting this wrong in the other direction is also real.

Cost of being wrong, in both directions

Here is a framing that helped us. If we pick Postgres and we are wrong, what does that cost? We hit a scaling wall sometime in the 12-month window if growth accelerates, and we do 3 to 6 weeks of migration work to move the notification system to a different store. We have the data to know when we are approaching the wall. We have the team to do the migration.

If we pick DynamoDB and we are wrong, what does that cost? We discover that cross-database queries against the user data in the monolith are harder than we estimated, we discover that the 4-person on-call rotation cannot reliably debug DynamoDB throttling at 3am, and we have no rollback because we built six weeks of product on top of it. The cost is similar in weeks but worse in confidence: we have a team that has learned a tool that did not serve them.

Both are recoverable. Neither is free. The interesting fact is that the recovery cost of being wrong about Postgres is more predictable than the recovery cost of being wrong about DynamoDB, because we have done one before and not the other. Predictable recovery is itself a form of insurance.

Why “the team already knows it” is a load-bearing argument

There is a class of engineering decision where “we already know how to operate this” is treated as a soft argument. It is presented as conservative, risk-averse, maybe even a little embarrassing - the implication is that a more sophisticated team would just learn the new thing. I want to push back on this framing.

Operational knowledge is not a static property of a person. It is a network effect across a team. Ana knowing Postgres at our scale is not just Ana’s personal expertise; it is the runbooks she has written, the alerts she has tuned, the failure modes the on-call rotation has rehearsed, the monitoring dashboards that already exist, and the muscle memory of every engineer who has paged into a Postgres incident. Replacing that network with DynamoDB is not a 2-week learning curve. It is a year of rebuilding it.

At a 50-person Series B, your operational capacity is one of the scarcest things you have. Spending it to adopt a new database needs to clear a high bar. “Better access-pattern fit” is a real argument, but it is the kind of argument that wins at 80 engineers, not at 8.

What we actually decided

We picked Postgres. We are building the notification service on a new schema in the existing primary cluster, with a queue backed by pg_notify and a jobs table. We have a documented revisit threshold (5M events/day sustained) at which we will pause and ask the question again, with the data we have by then.

Marcus is fine with this. Not because he changed his mind on access-pattern fit, but because he agrees that the operational argument is the load-bearing one given who we are right now. Priya has the decision for sprint planning. We will ship to production in three weeks.

The interesting thing about this decision, in retrospect, is how little of it was about Postgres or DynamoDB. The technical comparison took an hour. The operational comparison took two days. The hard part was getting honest about what kind of team we are, and what kind of mistakes we can afford to recover from.

If you are in a meeting like this next week, that is the question I would put on the whiteboard first. Not “which database fits the access pattern.” That one has an answer in a docs page. The harder question is: which of these mistakes can we recover from? Pick the database whose failure mode you already know how to survive.