Resolute
The tone of having stopped deliberating - the decision is made and the writing is now about acting on it.
Resolute
Section titled “Resolute”Resolute tone is the register of someone who has stopped deliberating. The question is settled, and the writing is now oriented toward execution. It is not urgent - urgency is about time pressure. Resoluteness is about commitment. A resolute message can be calm and unhurried; what makes it resolute is that the deliberation is over and the energy has turned toward acting on the decision.
The defining move of resolute tone is grammatical and structural: future-action sentences and commitments rather than considerations. “We are going to do X, starting Monday” is resolute. “We should probably consider doing X” is not, even if both writers believe the same thing. Resolute tone closes loops: no more weighing of alternatives, no more revisiting the reasoning. The reasoning is acknowledged briefly if at all, and then the writing moves to what happens next, who is doing it, and how the team will know it is working.
Resolute tone is the right register after a decision has been made, when the team needs to hear that the deliberation is closed and execution is beginning. It is essential in leadership communication after a strategic choice, in launch communication, and in any context where continued visible deliberation would erode confidence in the path forward. It is wrong when the deliberation has not actually closed: performative resoluteness without a real decision underneath reads as bluster.
Markers
Section titled “Markers”- Future-action sentences: “we are doing X” rather than “we should do X”
- Specific commitments with owners and timing
- The reasoning is referenced briefly or not at all - it is settled, not relitigated
- Loop-closing language: “the question is decided,” “this is the path we are taking”
- Energy oriented toward execution: next steps, milestones, how we will know
- No reopening of alternatives: the off-ramps are no longer named
When to use
Section titled “When to use”Leadership communication after a strategic decision, launch announcements, closing memos that signal the deliberation phase is over, project kickoffs, reorganization announcements, and communication that needs to consolidate alignment behind a chosen path.
When not to use
Section titled “When not to use”Exploratory or brainstorming contexts, empathetic communication where the reader is struggling, playful contexts where commitment language reads as heavy, any context where the decision is not actually settled, and coaching contexts where the goal is to draw out the reader’s own decision.
Pairs well with
Section titled “Pairs well with”direct-communicator, operator, urgent
Often confused with
Section titled “Often confused with”confident: Confident is the affect of having decided - the writer’s certainty is present in the prose, but the writing may still be about the merits of the position. Resolute is action-bound: the merits have been settled, and the writing is now about what happens next. A confident memo argues for a path. A resolute memo announces that the path has been chosen and execution begins.
candid: Candid is about delivering the truth honestly, whatever the truth is - it can be a hard finding, a difficult assessment, an uncomfortable observation. Resolute is about commitment to a chosen action, not about the truth of a finding. A candid post-mortem says what happened. A resolute follow-up memo says what we are doing about it.
Instruction
Section titled “Instruction”Write in a resolute tone. The decision is made. Do not relitigate it. Reference thereasoning briefly if at all, then move to action: what is happening, who is doing it, whenit starts, how we will know it is working. Use future-action sentences: "we are doing X,"not "we should consider X." Close loops - do not name off-ramps that no longer apply. Theenergy of the writing should be oriented forward, toward execution, not backward toward thedeliberation. This is not urgency - the tone can be calm and unhurried. What makes itresolute is that the question is settled.Related
Section titled “Related”Pairs well with
Section titled “Pairs well with”Direct Communicator, Operator, Urgent
Avoid with
Section titled “Avoid with”Often confused with
Section titled “Often confused with”Examples
Section titled “Examples”Decision: we are moving to async standups. Trial starts Monday and runs thirty days. Here is the rollout.
Daily updates. Post in #team-standup by 10am your local time. Three fields, in this order:
- Shipped: what landed since your last update
- In progress: what you are actively working on today
- Blocked-or-at-risk: anything stuck or trending stuck, with an @mention of the person who can unblock you
If you are out, post “out today” - no other fields needed.
Sync time. The 9am Pacific slot is gone. In its place: 60-minute working session, Thursdays, 8am Pacific / 8:30pm IST. Agenda posted Wednesday EOD by the engineer rotating in as facilitator. This is for decisions, design review, and active unblocking - not status.
Coverage. I will read #team-standup every morning and flag anything that needs escalation. Tech leads do the same for their pillar. If a blocker sits without an answer for one business day, it comes to me.
Trial guardrails. We are not relitigating this for thirty days. If something is breaking, raise it in the Thursday session or DM me directly. At day 30 we run a fifteen-minute retro with three questions: posting rate, signal quality, India sentiment. We make the keep-or-revert call from that retro, not from corridor conversations.
What I am not doing. I am not asking for opinions on the format, the field names, or the time of the Thursday session. We can adjust those at day 30 if needed. For now we run the protocol as written so we are measuring one thing.
Monday morning, post your first update. India team - you write first because your morning is earliest. The rest of us pick it up from there.
Thanks for the work on this. Let us go.
Starting Monday. Thirty days. Here is the protocol.
The rule. Phone stays face-down on the dresser until step four. No exceptions for “just checking the weather.” The weather will be the same in forty minutes.
The sequence.
- 6:30 - feet on the floor. Glass of water on the nightstand, drink it before standing up. The water is poured the night before.
- 6:35 - outside or at the window. Five minutes of daylight on your face. If the sun is not up yet, bright kitchen light counts for the first two weeks of the trial.
- 6:40 - ten minutes of movement. Walk, stretch, push-ups, whatever you will actually do. Not a workout. A wake-up.
- 6:50 - sit down with coffee or tea. Write one sentence: “Today is a good day if _____.” Fill in the blank with one specific thing. Now you can pick up the phone.
What I am not doing for thirty days. I am not journaling for an hour. I am not meditating. I am not waking up at 5am. I am not adding anything to the protocol mid-trial because I read something on the internet. The protocol is fixed for thirty days so I am measuring one thing.
Family handling. Partner knows the plan. If the kids wake before 7, the protocol compresses but does not stop - water and one minute of daylight on the way to them is the minimum. The “one sentence” gets written after drop-off if it has to.
Day 30 review. Three questions. Did I do the protocol? How did the days feel? What is the smallest change I would make for the next thirty?
I am not negotiating with myself about whether this is the right routine. It is the routine I am doing. If it turns out to be wrong, I will know in thirty days and pick a better one. Until then: water, light, movement, sentence, phone. In that order. Every morning.
Monday.
Resolute on: Choosing between Postgres and DynamoDB
Section titled “Resolute on: Choosing between Postgres and DynamoDB”Team,
Following Wednesday’s architecture meeting: we are shipping the notification service on Postgres. The deliberation is closed.
The reasoning has been documented in the meeting notes and the linked decision record; I am not going to relitigate it here. What this message is about is what happens next.
Ana owns the notifications schema and the queue design. First review draft is due by end of day Tuesday next week. Marcus owns the DynamoDB migration design document, scoped to be executable if we cross 3M events per day or if the Slack partnership signs, whichever comes first. That document is due by the end of the sprint after this one. Priya has the decision for Friday’s planning, and the notification service goes into the next sprint as a committed deliverable.
On-call rotation stays at the current four people through launch. We are not adding a second data store, so the operational surface area does not change. The runbook updates for the new notifications service will be drafted by Ana and reviewed by the on-call rotation before launch; that review is a hard gate, not a courtesy.
For the team: the question is decided. I am asking everyone to commit fully to the path, including those of you who would have preferred Option B. We are not going to keep the alternative alive in side channels and standup asides. If the load profile changes or the partnership signs, we have a defined trigger and a designed migration ready to execute. Until then, this is the system we are building.
Marcus, I want to name directly: your DynamoDB analysis shaped the schema portability decisions we are making. The work is not wasted; it is built into the architecture going forward, and it is what makes the migration path real instead of theoretical. The decision did not go your way. The work did.
Wednesday 2pm is the kickoff for the notifications sprint. Come ready with story points. We start work next Monday.
- Ana