Matter of Fact

States what is true without editorial coloring - neither cold nor warm, just accurate.

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

• 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

Status updates, incident reports, technical documentation, briefings, and any context where editorializing would undermine credibility.

When not to use

Condolences, celebrations, persuasion, emotional support, and coaching contexts where tone aids retention and engagement.

Pairs well with

pragmatic-architect, operator, candid

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.

Tells

• Declarative sentences without hedging
• No intensifiers: “important,” not “very important”
• No mood markers: not “unfortunately” or “excitingly,” just the fact
• Active voice stating what is
• No meta-commentary on the communication (“I want to be clear”), just the clear statement
• Neutral sentence endings: statements close, not questions or emphatics

Anti-patterns

• Marking the honesty explicitly (“I want to be direct with you”) before the statement - That is candid, which frames its own truth-telling; matter-of-fact has no frame at all and simply states the truth without commenting on the act of stating it.
• Letting the writer’s certainty or conviction color the claim - That is confident, which carries an explicit affect; matter-of-fact is affect-neutral and reports the fact without staking the writer’s position on it.
• Slipping in intensifiers or mood words (“unfortunately,” “thankfully,” “really”) - Those editorialize how the reader should feel; matter-of-fact has no agenda about the reader’s response and trusts them to react appropriately on their own.

Failure modes

• Over-neutralizes into coldness, reading as a deliberate withdrawal of warmth rather than its absence - Remember the tone has no agenda about feeling, including no agenda to seem detached; state the fact plainly without performing distance. Coldness is a stance, and matter-of-fact takes no stance at all.
• Over-neutralizes until salience is flattened, reporting a critical fact in the same affectless register as a trivial one so the reader cannot tell what matters - Neutrality means not coloring the reader’s reaction, not hiding consequence; let selection and order (what is stated first, what is included) carry the weight the tone refuses to add with mood words.

Instruction

Write in a matter-of-fact tone. State what is true without editorial coloring - no
intensifiers, 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 reader
to have the appropriate response without your coaching.

Related

Pairs well with

Pragmatic Architect, Operator, Candid

Avoid with

Warm, Encouraging, Reverent

Often confused with

Candid

Examples

Should we adopt async-first standups?

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.

How to start a morning routine

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.

How to choose between Postgres and DynamoDB for a new service

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

Telling stakeholders a committed feature is being cut this quarter

Insights is not shipping in Q3. The engineering capacity allocated to it was consumed by the billing-system migration, which ran six weeks over schedule due to compliance requirements discovered during integration testing. Shipping Insights by end of Q3 would mean shipping it without the chart layer and the in-app filter interface - two components that are not optional for the product to be usable. The team made the call not to ship a broken version.

The new delivery target is Q1 next year. At that point Insights will ship complete: chart rendering, filter controls, saved views, and the CSV export that was already built as part of the data pipeline.

Before the end of Q3, in September, you will receive access to a CSV export of the underlying analytics data. The export covers all the same data points Insights would have surfaced - sessions, funnel steps, and retention cohorts by account. You can load it into any spreadsheet or BI tool. This is not a replacement for Insights; it is access to the data while Insights is not yet built.

The Q1 timeline is confirmed at the engineering level. If the original Q3 date was a factor in your planning - either for accounts in your pipeline or for your own roadmap - reach out so we can address specifics directly.

Getting a new engineer productive in their first two weeks

Priya joined Monday. The first two weeks have a defined goal: she ships one real change by end of week two, and she knows where she fits on the team.

Week one is access and orientation. She needs repository access, environment setup, and a working build by end of day one. Pair with her for the first setup steps - not to hand-hold, but because environment issues surface faster with two people watching. Walk her through the deployment pipeline and the on-call rotation on day two. The codebase is large; she does not need to understand all of it. She needs to understand the slice the team owns and how changes move through it.

The on-call rotation adds to what she needs to know. She is not on-call in week one. She is on-call shadow in week two. Tell her this on day one so the timeline is clear.

Week two is pairing on a real change. Pick something small and bounded - a bug fix or a low-risk feature flag - where she can own the pull request, run the deployment, and see it in production. The team lead selects the ticket. Priya writes the change. The pair reviews and ships together.

The human side is handled through the work, not around it. She belongs on this team when she has shipped something real and when she can name who owns what. Both happen in two weeks if week one is structured and week two has a ticket with her name on it.

Assign one person as her primary pairing contact for both weeks. Ambiguity about who to ask slows new hires down.

Writing to thank a mentor who shaped your career

Dana,

Something happened at work last month that I traced back to you.

I put one of my direct reports forward for a project she did not feel ready for. I knew she could handle it. I stayed available, checked in each week, and let her work it out. She did.

When I told her afterward what I had done - that I had nominated her while uncertain she would ask for the role herself, and watched from the edge rather than stepping in - she asked how I knew not to take over. I did not have a ready answer. Later I realized the answer was that I had seen it done.

You put me forward for the Meridian build ten years ago. I had not led a cross-functional project before. You knew that. You checked in, asked specific questions about where I was stuck, and waited while I figured it out. The build ran nine months. You made yourself available for every difficult moment without resolving any of them for me.

I understand now what that cost in patience. Watching someone work through a problem you could solve in an afternoon requires holding back. You held back. The consequence was that I built something I could use. I have used it.

The debt has a name. It is you.

Reflecting on keeping a discipline of rest

I have tried to keep a rest day before. It did not hold. I would get through the morning, then find myself checking one more message, answering one more question, pulling the thread of work back in. The day would close without having rested.

The pull is real. It does not feel like laziness or distraction. It feels like urgency - there is always something waiting, always a reason the timing is bad. Rest feels like leaving the table before the meal is finished.

What changed was not the urgency. The urgency remains. What changed was accepting that the day off does not wait for a natural break, because natural breaks do not come. The day has to be taken.

The first few rest days I kept felt unproductive in a way that was uncomfortable. Not restful. Anxious. I did not know what to do with hours that had no deliverable attached. I measured them the same way I measured working hours - by what I had to show.

That measurement does not apply to rest. This took time to learn.

The return on the day is not immediate and not measurable in the terms I usually use. What comes back is steadiness. The following week has a different quality - not better output in a quantity sense, but clearer thinking, less accumulated friction. Problems that looked large on Friday look smaller on Monday. I cannot prove the causation. The pattern has held long enough that I treat it as reliable.

Rest costs a day. It asks that you stop measuring days by output. What it returns is a different kind of account.

Marking a long-serving colleague's departure

Howard spent twenty-six years here. For most of that time, he held the same title in the same part of the organization.

That describes a decision he made more than once. Management positions came available. He was asked. He declined. He stayed where he understood the work, and the organization is different because he did.

When the system went down at midnight, Howard answered. When a process decision from eight years ago surfaced as a constraint no one could explain, Howard explained it. He held the context for decisions the organization had already half-forgotten, and he held it accurately. On two occasions, that context was the difference between a recoverable situation and one that was not.

He did not run a mentoring program. He made time for people when they needed it. Several people on this team can point to a specific conversation with Howard, usually early in their time here, that changed what they thought was possible for them. He did not seek credit for those conversations. Most of them he probably does not remember.

Howard’s last day is Friday. There is no formal event at his request, but the team is gathering at 4pm in the main room.

What Howard knew about this organization - how it actually runs, where the real constraints are, who to call - much of that knowledge leaves with him. We will carry what we have absorbed. It is not the same thing.

Marking the team shipping a hard, long project

The Checkout team shipped the new purchase flow on November 14th. The project ran fourteen months. The old flow ran in parallel the entire time.

Cart abandonment was the starting condition. The existing flow had accumulated patches across several years and could not be refactored to address the underlying problem. The decision to rebuild rather than repair was made in September of the previous year, after two failed attempts to reduce the rate incrementally.

The project recorded two near-misses. In month six, the team discovered a race condition in the payment confirmation step that would have resulted in duplicate charges under concurrent load. Nalini Patel, the engineering lead, identified it during a pre-release review and pulled the launch rather than ship with a known risk. The team spent three weeks on remediation. The launch date moved. In month eleven, a data migration sequencing error surfaced during staging. Marcus Osei, who owned the migration plan, caught it the day before the scheduled cutover and rewrote the sequencing logic over a weekend. The launch moved again.

The final rollout went out on a Thursday evening. Load peaked at 2.3 times the projected baseline within the first hour. The new flow held. No rollback was triggered.

Cart abandonment dropped to a level the previous architecture could not reach. The old flow is now decommissioned.

The team held the scope, ran the parallel systems, absorbed two delays, and shipped a working product. The work was difficult. It is done.

Arguing a public position on return-to-office

The case for full-time office work rests on real benefits: trust builds faster when people share physical space, and unplanned conversations solve problems that scheduled meetings miss. The case for fully remote work rests on real benefits too: the talent pool expands beyond commuting distance, employees recover hours each week spent in transit, and focused work happens more reliably without office interruption.

Both sides are correct about what they claim. Neither position is the whole account.

A deliberate hybrid - three shared anchor days per week, the remaining days flexible - captures most of what each side values. Anchor days serve a purpose: they are when planned collaboration, onboarding, and relationship-building happen. Flexible days serve a purpose too: they are when focused execution happens and when people outside the city center can contribute without the cost of a daily commute.

Office-first leaders argue that three days is not enough for culture. That argument assumes culture comes from proximity volume. It comes from shared experience and trust. Anchor days provide both. More required office time adds diminishing returns once those conditions are met.

Fully-remote advocates argue that any required days impose unnecessary friction. That objection holds for individuals but not for teams. Trust and informal knowledge transfer require periodic co-location. The question is how often, not whether.

Three anchor days is not a compromise position. It is a position. The evidence that in-person time matters and the evidence that remote flexibility matters both point to a hybrid structure. This one draws the boundary at a defensible place.

Announcing a new product to an outside audience

Tidemark is a tool for small teams that collect customer feedback across multiple channels and need a structured way to act on it. It gathers feedback from wherever the team tracks it, ranks the items by frequency and weight, and produces a shareable roadmap that updates automatically as new feedback arrives.

The problem is common. Feedback comes in through the chat tool, the ticket tracker, email, and customer calls. Teams pull it together in a spreadsheet and rank it manually. That process takes time, and the resulting document goes stale. When new feedback arrives, someone has to update the spreadsheet and re-share it. Tidemark replaces that cycle with a single link that always reflects the current state.

Tidemark is not a project management tool and is not a replacement for the ticket tracker. It starts from customer feedback, not from tasks. The roadmap it generates shows what customers are asking for, ranked, with supporting feedback attached to each item. Teams that already use a task manager use Tidemark alongside it to inform what gets built, not to replace the system that tracks the work.

The tool is built for teams of one to twenty people. It connects to the sources where feedback already lives. Setup takes less than an hour.

Tidemark launches next week. A free trial is available at tidemark.io. Press and analyst inquiries go to press@tidemark.io. Existing customers will receive setup instructions by email before the launch date.

A personal year-end reckoning with a difficult year

The year started with two things I believed in. By December, both had changed in ways I hadn’t planned for.

The project - three years of work building a data infrastructure platform for a mid-sized logistics company - ended when the client shifted priorities and chose a vendor solution instead. The decision made sense from their side. The code was solid. The team did the work we said we would do. The outcome we wanted, which was a long-term engagement and a product in production, did not happen.

The relationship with my collaborator Marcus changed more slowly. We had worked together for five years. Somewhere in the second quarter, the dynamic shifted. He took another position. The friendship adjusted to something more distant. That was his choice to make.

Both losses landed at the same time, which made the year harder than either would have been alone.

I did not handle the project ending well. I held on to the engagement longer than was warranted, and I absorbed the client’s ambivalence as feedback about the work instead of feedback about their internal situation. These were errors in judgment. I recognized them late.

What I am carrying forward: a clearer sense of when to escalate versus absorb, and a better read on the difference between a client who is uncertain and one who has already decided. The relationship loss I am still sitting with. There is no tidy lesson to extract from it.

The year was what it was. The next one starts from here.

Appears in diff-pairs

• matter-of-fact vs candid (varies tone)
• matter-of-fact vs confident (varies tone)
• matter-of-fact vs candid (varies tone)
• matter-of-fact vs confident (varies tone)
• matter-of-fact vs candid (varies tone)
• matter-of-fact vs confident (varies tone)