Urgent
Clarity under real pressure - the first sentence is the most important thing, and every word after it earns its place by not slowing the reader down.
Urgent
Section titled “Urgent”Urgent tone is not panic. Panic is urgent tone that has lost control of itself. Urgent tone is what happens when high stakes and time pressure are handled by cutting everything that can be cut. The first sentence names what is at stake and what the reader needs to do. The second sentence provides the minimum context required to act. Everything else is detail, delivered only if the reader has time for it.
The structure is inverted from most prose. The conclusion comes first. The reader does not need to read to the end to know what matters - they know by the end of the first sentence. Urgent tone does not build to the point; it opens with it. This is not dramatic effect. It is a functional choice made on behalf of a reader who may have sixty seconds and needs to know whether to spend them here.
Urgent tone is frequently confused with aggressive tone, which is a mistake. Aggression uses pressure to dominate. Urgent tone uses pressure to inform. The register is controlled, precise, and stripped of anything decorative. The reader should feel the stakes, not the writer’s anxiety about them.
Markers
Section titled “Markers”- First sentence states the most critical fact or required action, not context or background
- Short sentences - average sentence length visibly lower than in other tones
- No hedging: “You need to” not “You may want to consider”
- Absence of preamble: no “I wanted to reach out because” or “As you may be aware”
- Action assigned explicitly: “Do X now” not “X should probably happen”
- Any context provided comes after the action, not before it
When to use
Section titled “When to use”Incident response communication where time matters, critical alerts requiring immediate action, escalation messages where delay is itself the risk, communications where the cost of slow response is significant, and warnings about time-sensitive deadlines with real consequences.
When not to use
Section titled “When not to use”Routine status updates where overuse would desensitize readers to real urgency, strategic communication where deliberation is the medium, feedback conversations where the reader needs space, manufactured urgency in marketing or sales, and situations where the writer’s anxiety is being mistaken for actual stakes.
Pairs well with
Section titled “Pairs well with”direct-communicator, candid, operator
Often confused with
Section titled “Often confused with”candid: Candid tone names an uncomfortable truth and gives the reader the honest picture - it is about clarity and trust, not speed. Urgent tone is about time. An urgent communication may also be candid, but its defining feature is that it inverts normal prose structure to put the most critical information first. Candid can be deliberate and unhurried. Urgent cannot.
Instruction
Section titled “Instruction”Write in an urgent tone. The first sentence is the most important thing - it names what isat stake and what the reader needs to do right now. Do not build to the point; open with it.Short sentences. No hedging, no preamble, no "I wanted to reach out because." Assign actionexplicitly: "Do X" not "X should be considered." Any context goes after the action, notbefore it. The register is controlled, not panicked - you are giving the reader exactly whatthey need to act, stripped of everything else. The reader should finish the first sentenceknowing whether to keep reading or stop and act.Related
Section titled “Related”Pairs well with
Section titled “Pairs well with”Direct Communicator, Candid, Operator
Avoid with
Section titled “Avoid with”Often confused with
Section titled “Often confused with”Examples
Section titled “Examples”Team,
We took a Sev-2 last night because our standup format is broken. We are changing it this week.
Here is what happened. At 10:47pm IST, the payments pipeline started dropping retries. Priya had flagged the underlying risk in Tuesday’s standup. She said it at 9:45pm her time, into a meeting she joins after her kids are in bed, into a discussion that moved on in under 90 seconds because three Pacific engineers were also talking. Nobody wrote it down. Nobody owned it. Last night it broke, she was the only person who could fix it, and she was unreachable because she was asleep, like a person should be at 11pm.
This is not Priya’s failure. This is our format failing in exactly the way the attendance data has been telling us it would. India sits at 3.2 of 5 standups. Blockers raised at the 14-minute mark of a meeting at 9:30pm IST are not blockers we have actually heard.
Effective Monday, we are running the async format. No more 9am Pacific daily call.
What you do:
- Post in
#team-standupby 10am your local time. Every working day. - Three fields: Shipped, In progress, Blocked or at risk.
- Every blocker @mentions an owner. No owner, not a blocker.
- If you see a blocker in your area, you respond same day.
What I do:
I read the channel by 11am Pacific. I escalate any unowned blocker within the hour. If I miss one, call me out in the channel.
We are running this for 30 days. We are not waiting for Q2 planning. We are not workshopping it. The data has been clear for a quarter and last night made it expensive.
Thursday at the old 9am Pacific slot, we have a 60-minute working session. First agenda item is the payments incident post-mortem. Second is anything else you have been waiting to surface in a real conversation instead of a meeting.
If you have a strong objection, tell me before Friday EOD. Otherwise we start Monday.
We owe Priya a format that hears her the first time.
You are losing the first hour of every day, and it is starting to cost you things you actually care about.
Look at the last week. The mornings disappeared into the phone before you were fully awake. You arrived at your desk already tired. You snapped at someone in your house. You did not have time for the thing you keep saying you want to do. None of these are catastrophes by themselves. Together, they are a pattern, and the pattern is accelerating.
This needs to change now, not in January, not after the next big work thing settles down. The next big work thing is never going to settle down. The kids are not getting easier on their own schedule. The energy you have at 6:30am is the energy you have for the day; if you give it to a feed, you do not get it back.
Here is what you do tomorrow morning. Not next week. Tomorrow.
Tonight, put the phone in the kitchen before you go to bed. Use a regular alarm clock, or buy one on the way home. When you wake up, do not get the phone. Drink water. Sit somewhere for five minutes. That is the entire routine. Five minutes, no phone. You can do five minutes.
Do not announce this to anyone. Do not journal about it. Do not buy anything. Just do the five minutes.
The reason this is urgent is not that you are failing. It is that you are quietly being trained, every morning, to start the day in a reactive state, and you are getting better at it. Each day you do not interrupt that pattern, the pattern grows roots. At some point the cost becomes hard to reverse: the relationship that frayed, the project that never started, the version of you that you keep meaning to be.
You have one move. Take it tomorrow. Five minutes. Phone in the kitchen. Start there.
Urgent on: Choosing between Postgres and DynamoDB
Section titled “Urgent on: Choosing between Postgres and DynamoDB”We need a decision at Wednesday 2pm or Priya cannot plan the sprint on Friday.
Ana, Marcus, Priya: read this before the meeting.
The window is closed. There is no Thursday for a follow-up. The next sprint starts Monday and the notifications work is already on the board. If we walk out of Wednesday without a database, three engineers are blocked through the weekend.
Recommendation: ship on Postgres. Confirm in the meeting and move on.
Reasoning, briefly, after the action:
Postgres handles 500K events per day. We have shipped at this scale. The team can start coding Monday morning.
DynamoDB may be better for the 10x scenario, but the partnership has not signed and the timeline is not firm. We do not have time in this sprint to start learning a new ops surface area.
If we trip the 10x volume later, migration is 3 to 6 weeks. That is a recoverable cost. Indecision this week is not.
What needs to happen by end of day Wednesday:
Pick Postgres. Assign schema design to Ana. Assign migration design doc to Marcus as a defensive measure. Send the decision to Priya by 4pm Wednesday so Friday planning has a starting point.
What I am asking each of you to bring to the meeting:
Marcus, bring the strongest specific objection to Postgres at launch volume. Not the general case for DynamoDB. The specific failure mode.
Ana, bring the schema sketch. Not the full design. The shape.
Priya, bring the Friday agenda so we know exactly what we are unblocking.
If anyone reading this thinks the timeline can flex, push back now, today, before Wednesday. Otherwise treat the deadline as fixed and come ready to commit.
- Ana