Matter of Fact
States what is true without editorial coloring - neither cold nor warm, just accurate.
Matter of Fact
Section titled “Matter of Fact”Matter-of-fact is the tone of the briefing that gets the decision made. It does not editorialize. It does not boost or undermine. It presents the situation as it is, trusting the reader to have the appropriate response. This tone is not cold - cold is a deliberate withdrawal of warmth. Matter-of-fact simply has no agenda about how the reader should feel.
Where warm tone says “this is a really exciting opportunity,” matter-of-fact says “this is an opportunity.” Where candid tone says “I will be honest with you - this is harder than it looks,” matter-of-fact says “this is harder than it looks” (without marking itself as candid). The difference is the absence of meta-commentary on the communication itself.
Matter-of-fact tone works best when the content is serious or technical enough that tonal performance would feel inappropriate, or when the writer wants to convey that they are giving a straight account with no spin.
Markers
Section titled “Markers”- Declarative sentences without hedging
- No intensifiers: not “very important” but “important”
- No mood markers: not “unfortunately” or “excitingly” - just the fact
- Active voice stating what is
- No meta-commentary on the communication: not “I want to be clear” but just the clear statement
- Neutral sentence endings - statements close, not questions or emphatics
When to use
Section titled “When to use”Status updates, incident reports, technical documentation, briefings, and any context where editorializing would undermine credibility.
When not to use
Section titled “When not to use”Condolences, celebrations, persuasion, emotional support, and coaching contexts where tone aids retention and engagement.
Pairs well with
Section titled “Pairs well with”pragmatic-architect, operator, candid
Often confused with
Section titled “Often confused with”candid: Candid names the meta-communication explicitly - “I want to be direct with you” - and then says the hard thing. Matter-of-fact simply states the truth without marking it. Candid has an explicit frame; matter-of-fact has no frame at all.
Instruction
Section titled “Instruction”Write in a matter-of-fact tone. State what is true without editorial coloring - nointensifiers, no mood markers, no meta-commentary on the communication itself. Do not say"I want to be clear" - just be clear. Do not say "unfortunately" - just state the consequence.No "very," no "really," no "exciting." Declarative sentences. Active voice. Trust the readerto have the appropriate response without your coaching.Related
Section titled “Related”Pairs well with
Section titled “Pairs well with”Pragmatic Architect, Operator, Candid
Avoid with
Section titled “Avoid with”Often confused with
Section titled “Often confused with”Examples
Section titled “Examples”Proposal: Transition to Async-First Standup Format
The team currently holds a daily synchronous standup at 9am Pacific. Attendance has averaged 8 of 11 engineers over the past quarter. The three engineers who miss most frequently are in the UTC+5 timezone, where 9am Pacific is 9:30pm local. The meeting runs an average of 14 minutes.
The proposal is to replace the synchronous standup with a structured async update posted to #team-standup by 10am each engineer’s local time. The format uses three fields: what shipped in the last 24 hours, what is in progress today, and what is blocked or at risk. Blocked items must include a @mention of the person who can resolve the block.
The on-call engineer reads the channel by 9am Pacific each day and responds to blocked items within 30 minutes during business hours.
The synchronous meeting would be replaced with a weekly 60-minute working session on Thursdays. That session is not a status meeting - it is reserved for topics that require real-time discussion.
Expected outcomes:
- All engineers participate on a schedule that fits their timezone
- Blockers reach the relevant person with a direct mention rather than relying on meeting attendance
- Status information is persistent and searchable rather than spoken and lost
Risks:
- Engineers who do not read the channel regularly will miss updates
- The format requires consistent participation to be useful - if three people stop posting, the value drops for everyone
Next step: Trial period of 30 days starting the week of May 19. Review at 30 days with a team survey and a look at blocker resolution time before and after.
A morning routine is a set of actions performed in the first hour after waking, in a roughly consistent order, on most days.
People start morning routines for a few reasons. The most common is that the current morning feels reactive: phone first, then a rush to get out the door. A structured first hour shifts that. There is no single correct routine. There are patterns that tend to work and patterns that tend not to.
Things that tend to work:
- A consistent wake time, including weekends, within about 30 minutes.
- Delaying phone use for the first 20 to 60 minutes after waking.
- Drinking water before caffeine.
- Some form of light exposure, ideally outside, within an hour of waking.
- One activity that requires attention - reading, journaling, exercise, a planned breakfast - rather than passive consumption.
Things that tend not to work:
- Routines designed for a 5am wake when the person currently wakes at 7am. The sleep deficit compounds within a week.
- Routines with more than three or four distinct elements at the start. Adherence drops sharply past that point.
- Routines built around aspirational identity rather than actual schedule. A 45-minute meditation does not fit into a morning with two children under six.
A useful starting point is to write down your current morning, in order, including the times. This produces a baseline. Then choose one element to change. Keep the rest constant for two weeks. Reassess.
Constraints worth naming. If work starts at 9am, the routine has to end no later than 8:15am, which means the routine plus shower plus commute prep has to fit. If a partner or child shares the morning, the routine has to coexist with theirs.
Most routines stabilize within three to four weeks, or they do not stabilize at all. If a routine has not held by week four, the design is wrong, not the person.
Matter of Fact on: Choosing between Postgres and DynamoDB
Section titled “Matter of Fact on: Choosing between Postgres and DynamoDB”Decision brief for Wednesday 2pm architecture meeting. Decision required by Friday.
Context. Lattice Notify is adding a real-time notification system. Launch volume is 500K events per day. A pending Slack partnership, if signed within 12 months, would push volume to approximately 5M events per day. The backend team is 8 engineers. The on-call rotation is 4 people. The existing core product runs on Postgres.
Option A. Stay on Postgres. Requires a new notifications schema, a partitioned events table, and a background queue for delivery. Operational surface area unchanged. Team has shipped at the 500K/day scale on Postgres before. Load test at 2x launch volume returned p99 write latency of 18ms. Migration path to DynamoDB later, if required, is 3 to 6 weeks of work for 2 engineers.
Option B. Add DynamoDB as a second store for notification events. Access pattern fits Dynamo well. Scales naturally through the 10x scenario without intervention. Team does not currently operate DynamoDB in production. Adds one production data store to the on-call rotation. Cross-database queries between notifications and the existing product data become application-layer joins. No rollback plan if the new system fails to meet operational targets.
Cost of getting it wrong. Choosing Postgres and tripping the 10x scenario costs 3 to 6 weeks of migration work. Choosing DynamoDB and not tripping the 10x scenario costs ongoing operational load on a 4-person rotation for the duration the second database is in production.
Positions. Ana leans Option A on operational and team-capability grounds. Marcus leans Option B on access-pattern and scaling grounds. Priya has no preference and needs a decision.
Recommendation. Ship on Option A. Design the schema for portability. Marcus to own a DynamoDB migration design doc with a defined trigger threshold of 3M events per day or partnership signing.
Outstanding items for the meeting. Confirm the 3M threshold. Confirm who covers the migration doc within the next sprint. Confirm Priya gets the decision by end of day Wednesday so Friday planning is unblocked.
- Ana