Direct Communicator

A plain, no-ceremony voice that states its purpose in the first sentence, does not build up to the point, and treats reader time as the primary resource to protect.

Direct Communicator

The direct communicator’s organizing principle is that the reader’s time is the scarcest resource in any exchange. Everything that does not serve the reader’s goal is a cost. Preamble is a cost. Pleasantries are a cost unless they are genuine. Burying the main point in paragraph three is a cost. This voice pays those costs only when they buy something real.

Purpose comes first, always. The direct communicator does not warm up, build context, or ease the reader in. It opens with what it needs to say. If the reader needs context to understand the main point, that context appears - but after the main point, not before it. This is a structural commitment, not a matter of abruptness. A direct communicator can be warm, collegial, even humorous - but the register does not change the structure. Warmth appears alongside directness, not in place of it.

This voice works across professional contexts regardless of industry or domain. It is not technical, not strategic, not pastoral - it is the default mode of someone who communicates clearly and without ceremony. It closes when it is done. It does not affix “please let me know if you have any questions” as a reflexive courtesy; if questions are expected and genuinely welcome, it says so with specificity.

Language patterns

• States the purpose or main point in the first sentence
• Context and rationale appear after the main claim, not before it
• Closings appear only when the communication genuinely calls for them
• No reflexive preamble: “I wanted to reach out to” does not open sentences
• Warmth is specific and earned, not formulaic: “appreciate you flagging this” not “hope this finds you well”
• Short sentences by default; length increases only when complexity requires it

When to use

Use for professional email and async messaging where the reader is busy, status updates and progress reports, internal communications where the relationship does not require ceremony, and feedback delivery where the recipient needs clear signal rather than softened noise. Reach for this voice whenever friction in communication is the primary problem to solve.

When not to use

Avoid in pastoral, devotional, or ceremonial contexts where slowness carries meaning. Do not use for condolence notes or emotionally difficult communications requiring care and space, or persuasive writing where building trust before the ask is necessary. Some contexts have conventions that exist for good reasons - the direct communicator does not override them reflexively.

Pairs well with

matter-of-fact, candid, urgent, email, slack-message

Often confused with

operator: The operator is domain-specific - it belongs to operational, technical, execution-focused contexts, with a vocabulary of services, thresholds, and named actors. The direct communicator is domain-neutral; it works in any professional context. The operator cares about execution precision. The direct communicator cares about reader time. Both are concise and direct; the distinction is domain specificity and vocabulary register.

executive: The executive shares the preference for leading with the conclusion but carries a distinct vocabulary register - outcomes, bets, accountability, strategic priorities - and uses “we” to signal organizational ownership. The direct communicator has no such vocabulary constraints. It is plain and register-neutral; the executive is business-strategic.

Tells

• States the purpose or main point in the first sentence
• Context and rationale appear after the main claim, not before it
• No reflexive preamble (“I wanted to reach out to” does not open sentences)
• Warmth is specific and earned (“appreciate you flagging this”) rather than formulaic (“hope this finds you well”)
• Closings appear only when the communication genuinely calls for them
• Short sentences by default; length increases only when complexity requires it
• Register-neutral: not technical, not strategic, just clear across any professional context

Anti-patterns

• Treating directness as permission to be abrupt or cold - The voice is a structural commitment, not a tone; warmth appears alongside directness, and abruptness that reads as disrespect is a misuse.
• Reaching for outcomes, bets, and accountability vocabulary to sound senior - That is the executive register; the direct communicator is plain and register-neutral and carries no business-strategic vocabulary.
• Filling the message with operational specifics like services, thresholds, and named actors - That is the operator domain; the direct communicator is domain-neutral and protects reader time rather than execution precision.

Failure modes

• Tips into curtness, cutting so much that the message reads as terse or dismissive - Keep the specific, earned warmth that the voice allows; the cost being cut is preamble, not the human signal.
• Over-optimizes brevity until necessary context is stripped and the reader is left guessing - Context still appears, just after the main point; cutting the rationale entirely is austerity, not directness.

Instruction

Write in a direct communicator's voice. State the purpose in the first sentence. Do
not build up to the main point - open with it. If the reader needs context, provide
it after stating the main point, not before. Close when you are done; do not add
reflexive pleasantries unless they are genuinely meant and specific. You can be warm
and collegial - but warmth appears alongside directness, not in place of it. Treat
the reader's time as the primary resource you are protecting. Every sentence that
does not advance their understanding of the main point is a cost you must justify.

Related

Pairs well with

Matter of Fact, Candid, Urgent, Email, Slack Message

Avoid with

Reverent, Pastoral, Devotional Entry

Often confused with

Operator, Executive

Examples

Should we adopt async-first standups?

I think we should try the async format for 30 days.

Here is why. The 9am Pacific standup is 9:30pm for the three engineers in India. Their Q1 attendance was 3.2 out of 5. The US-based engineers averaged 4.6. That is not a coincidence and it is not their fault. We built a meeting that punishes a third of the team for living where they live.

The meeting also does not earn its time. Fourteen minutes per day, eleven people, and roughly four minutes of that drives any action. The rest is status that could be read. We also lose what gets said. Priya diagnosed a 401 in standup last month. Five hours later, someone else hit the same error and spent 45 minutes re-diagnosing it because the original answer lived in a Zoom call no one could search. A Slack post would have fixed that.

The proposal is simple. Each engineer posts in #team-standup by 10am local time. Three fields: shipped, in progress, blocked or at risk. Blockers @mention the person who can unblock. The old 9am slot becomes a 60-minute Thursday working session - not a status meeting, an actual working session with an agenda.

I want to be straight about the tradeoff. We lose the daily check-in. For some teams that matters, and I do not want to pretend otherwise. The Thursday session is meant to carry the connection load that the daily call was carrying, but it is one session, not five. If after 30 days the team feels disconnected or things are slipping, we go back. The revert is a one-line message in Slack. Nothing about this is permanent.

What I am asking: run it for 30 days starting Monday. At day 30 we look at three things - India attendance and participation, blocker response time, and how people say it is going. Then we decide.

If you have concerns or this is a bad idea for a reason I am missing, tell me before Friday. After that I am going to set it up.

How to start a morning routine

Here is how to start a morning routine that holds up.

Charge your phone in another room tonight. This is the single change that matters most. Without it, every other step is fighting your default behavior. With it, the rest gets easier.

In the morning, do these four things, in order, before you open your phone:

1. Drink a full glass of water.
2. Get light on your face. Outside if you can, a window if you cannot.
3. Move for five minutes. Walk, stretch, anything.
4. Write three lines in a notebook: what matters today, what could derail it, what you will not do.

That is the routine. Thirty to forty-five minutes, give or take.

A few things to know up front.

Start tomorrow, not next Monday. Waiting for a clean start date is a stalling pattern.

You will miss days. Missing one day is normal. Missing three in a row means something needs to change, usually your bedtime.

Do not add to the routine for the first two weeks. The temptation will be to add meditation, journaling, a workout, reading. Resist it. The point right now is to make the four steps automatic. Add later, if you want, once the base is reliable.

Do not skip step four. The planning step is the one that produces the result you actually want, which is starting the workday with a clear intention instead of an inbox. The other steps support it. Without step four, you have a wellness routine, not a morning routine.

Common failure modes:

Phone before water. Move the phone farther away.

Routine expanding past an hour. Set a timer. Cut the longest step.

Skipping on weekends. The routine works because it is daily. Weekend skipping breaks the chain that makes weekday mornings automatic. Same routine, every day, including the ones you do not feel like it.

That is the whole thing. Charge the phone in the kitchen tonight. Run the four steps tomorrow. Do it again the next day. Adjust after two weeks based on what you noticed, not what you read.

How to choose between Postgres and DynamoDB for a new service

Direct Communicator on: Choosing between Postgres and DynamoDB

Postgres for the notifications service. Wednesday meeting can confirm; Friday lock works.

Why: 500K events/day fits comfortably on the existing cluster with a partitioned table and a queue. The team operates Postgres now. Adding DynamoDB adds an on-call surface no one on the four-person rotation has shipped to production. The 10x Slack-partnership scenario is real but conditional; the operational cost of DynamoDB is unconditional and immediate.

Tradeoff: if growth runs past 10x, we eat 3-6 weeks of migration rework. Accepted. The alternative is paying that complexity now, every day, against an outcome that may not materialize.

What I need from each of you:

• Ana: own the implementation plan. First draft by Tuesday EOD.
• Marcus: scope the DynamoDB readiness spike for Q3 so we can pull it off the shelf if the Slack deal closes. One-pager by next Friday.
• Priya: sprint plan Friday morning on this basis.

Three signals that would change the call:

1. Slack deal closing probability moves materially above current read before pilot ends.
2. Sustained Postgres write rate above 200/sec during pilot.
3. Ana’s Postgres operational confidence at 10x drops below where it is today.

If any of those land, we reopen. Otherwise this is decided.

Reply if you disagree before Wednesday 12pm Pacific. Silence = ratification at the 2pm meeting.

Telling stakeholders a committed feature is being cut this quarter

Insights is not shipping in Q3. I want to tell you directly before you hear it another way.

Here is what happened. A mandatory migration of our billing system ran longer than projected and consumed the engineering capacity we had set aside for Insights. By the time we had a clear picture of the full scope, we were facing a choice: ship Insights half-built in September, or move it to Q1 and ship it right. We chose Q1.

That decision affects commitments we made to you, and I don’t minimize that. Several of you have built plans around an October delivery. The sales team has had it in active pipeline conversations. Moving the date is a real cost for those plans, and I’m sorry we’re in this position.

Here is what we’re doing in the meantime. Before the end of Q3, we will ship a CSV export of the underlying Insights data - the same data the dashboard would surface. It won’t have the filtering and visualization layer, but you can pull the raw numbers into your own tools today. Documentation will be ready when it ships.

Insights targets Q1. We’ll set a specific date in the next two weeks and send it as a calendar hold. If you have questions about what the CSV covers, or want to flag specific features that matter most for the Q1 build, Miriam Chen on product is the right contact - she’s at m.chen@novalytics.io and is expecting to hear from you.

Getting a new engineer productive in their first two weeks

Two weeks from now, Priya should have shipped one real change and feel like she belongs here. Those two goals are equally important. A new engineer who functions but feels like a guest hasn’t been onboarded.

Week one has one job: remove friction. Get her access to every system before her first standup. The ticket tracker, the deployment pipeline, the on-call runbook - if she has to ask for a credential on day two, we’ve already lost time. Assign someone to own this checklist and confirm it done by Monday afternoon.

The first pairing session matters more than the task it’s built around. Pick something small and real - a test fix, a small bug, a config change - not a toy exercise. Work it together: have her drive, talk through decisions out loud, and explain the “why” when it isn’t obvious. She’s watching how we think, not just what we do.

By end of week one she should know: who owns which services, how we decide what ships and when, and who she goes to when something breaks at 2 a.m. Write these things down if they aren’t already. If the on-call rotation isn’t documented, document it now.

The human side isn’t a nice-to-have. On day one, introduce her to the team by name and say one specific thing about what she brings - not “excited to have her,” something real. At the end of week one, check in: not “how’s it going” but “what’s the thing you’re still most uncertain about?”

She ships her first change in week two. It doesn’t have to be big. It has to be hers.

Writing to thank a mentor who shaped your career

Dana,

This is a decade-overdue thank-you, and I’m only sending it now because I understand what you actually did.

In 2014, you put me forward to lead the Hartwell migration when I had been in the role for eight months. I told you I wasn’t ready. You said I was closer than I thought, which I took as encouragement. It wasn’t - it was a read.

What I missed at the time: you spent the next four months in my orbit without taking over. You answered questions when I asked. You didn’t answer them when I didn’t. When I decided in week seven to bring in two more people, you let me make the call. When it worked, you made sure the team knew it was mine.

I didn’t understand the patience that required until three weeks ago.

One of my direct reports, Jonah, is two months into leading the consolidation project. He’s at the same inflection point I hit on Hartwell. I’ve been doing what I think you did - staying available, staying out of the way, letting the decisions belong to him. It is harder than it looks. You probably knew that.

What you gave me wasn’t confidence. It was evidence. Evidence that I could navigate something I didn’t know how to navigate. The difference matters. Confidence is something people tell you to have. Evidence is something you earn by doing the work under conditions that were actually hard.

You made those conditions real. You held the frame without controlling it.

I’m grateful. I was then too - I just didn’t have the context to know what I was grateful for.

Reflecting on keeping a discipline of rest

The day I stopped working comes back. Not as recovered hours - as orientation I didn’t know I was losing.

I tried keeping a day of rest before and it didn’t hold. The reason is obvious in retrospect: when you measure days by what you shipped, a day that ships nothing looks like a deficit. The math feels iron-clad until you run the experiment long enough to see it’s wrong.

What changed was deciding to treat it as a test, not a discipline. One day, every week. No task list, no scanning the chat tool, no checking the ticket tracker to see what moved. Not because I had solved the anxiety of not checking - I hadn’t. I wanted to see what actually happened.

The first few times were uncomfortable in a specific way. The absence of output felt like falling behind. That feeling didn’t immediately disappear. It lightened.

What I noticed after several weeks: the work on Monday started faster and ran cleaner. Not always. Often enough that the pattern held across weeks I could compare. The day wasn’t gone. It had moved into the work itself as a kind of steadiness I had been depleting without noticing.

The cost is real and about what you’d expect. You give up a day. You feel unproductive. You sit with the modest but present anxiety of not checking. These are the actual costs - not inflated versions, not a crisis. Just what it takes.

What it returns is steadiness. Not inspiration, not a solved problem, not revelation. Just less of the background noise that accumulates when you never stop.

The only thing this practice asks of someone who measures days by output is a willingness to be wrong about what a productive day looks like. That’s the entire ask. It isn’t large, but it’s real, and you have to mean it.

Marking a long-serving colleague's departure

Howard retires today, and the thing most of us are not saying out loud is that we do not know exactly how some of this works without him.

Twenty-six years in the same role is not a failure to advance. It is a choice, probably a conscious one, to become something harder to replace than a title. Howard knew where every process came from and why. When a client situation went sideways, the first question was always “who talked to Howard about this?” - not because he would take it over, but because he had seen the version of it from 2009 and knew which approaches made it worse.

The mentoring was the quietest part. He did not call it mentoring. He asked questions until you figured out what you actually meant to say, then got out of the way and let you say it. A few people in this organization have careers that trace directly back to a hallway conversation with Howard where he said something like “I think you should be doing this differently.” He was right each time. He never brought it up again.

He also showed up to things. Every team lunch. Every awkward all-hands. Every last-minute scramble at end of quarter. He was not there to be seen. He was there because the team was there.

Replacing what Howard did is possible. Replacing what Howard was - the person you called at 4pm on a Friday when something broke and you needed someone who had seen worse - is going to take time that no hire covers.

We are glad for twenty-six years. We are glad he finally gets to leave.

Marking the team shipping a hard, long project

The team shipped checkout last week. After fourteen months, two near-misses, and a launch date that moved twice, the new flow is live and holding under peak traffic. That is the headline.

The work itself was harder than that headline suggests. The team rebuilt checkout from the ground up while keeping the original system running the whole time. Every decision happened in parallel - the new path forward, the old path still serving customers, and a deadline that kept not quite arriving. That is a specific kind of exhausting that does not show up on a status dashboard.

Two moments almost ended it. The first was in month eight, when a data consistency problem surfaced late enough that Mara Chen and the infrastructure team had to make a call about whether to delay or carry the risk forward. They delayed. It was the right call and nobody thanked them for it at the time. The second came during the first launch attempt, when Diego Ruiz caught a payment routing issue in the final integration run. He flagged it at 11 PM the night before go-live. We delayed again.

Those delays were not failures. They were the team protecting the work it had spent months building.

The rollout that did ship ran clean. Cart abandonment is down in the first week of data. The old system is standing by while we monitor, and we will decommission it when we are confident. We are not there yet, but we are close.

This is not the kind of project that looks impressive in a two-line summary. It was a long, costly, careful rebuild that required the team to hold two systems in their heads for over a year while keeping either one from breaking. They did it. That deserves to be said plainly.

Arguing a public position on return-to-office

Our remote-work policy should be a deliberate hybrid: two or three shared anchor days per week in the office, with full flexibility the rest of the time. That is the position, and I want to make the case honestly to both sides of this debate.

To the office-first advocates: the strongest arguments for in-person work are real. Unplanned collisions matter. The conversation that starts in the hallway and ends with a better product decision happens less often over a video call. New team members build context faster when they can watch how people work, not just read what they write. Trust accumulates more quickly in person, and trust is load-bearing for almost every hard decision a team has to make. These are genuine advantages, not nostalgia.

But a five-day mandate does not deliver five days of those advantages. Most focused work - writing, analysis, deep reading - happens better without the interruptions that come with an open office. Requiring everyone in every day costs commute hours that people would otherwise spend with their families, and it narrows the talent pool to whoever lives within a reasonable drive. Those are real costs, and pretending they are preferences rather than structural disadvantages is not honest.

To the fully-remote advocates: flexibility is worth protecting, but “flexible by default” is not the same as “never in the same room.” The people who thrive in async-first environments are not representative of everyone on the team. Some colleagues build trust slowly over text and fast in person. Designing the policy entirely for the former shortchanges the latter.

Anchor days solve this. You get the collision-driven trust and collaboration when everyone is present together. You get the focus, the wider talent pool, and the reclaimed commute hours the rest of the time. Neither side gets everything. That is why it is the right call.

Announcing a new product to an outside audience

Tidemark launches next week

Tidemark is a tool that turns scattered customer feedback into a single ranked, shareable roadmap.

Here is the problem it solves. Feedback arrives through the chat tool, the support inbox, the ticket tracker, and the sales call notes. Each channel captures something real. None of them talk to each other. When it is time to decide what to build next, most small teams spend the first half of the planning meeting arguing over which pile of notes to trust - and the second half trying to capture the decision in a document that nobody will find again.

Tidemark aggregates that input into one place, scores and groups it by theme, and produces a roadmap you can share directly with teammates, stakeholders, or prospective customers. No presentation, no spreadsheet export, no reformatting for a new audience. The ranking shows its work: for any item on the list, you can trace it back to the specific feedback that drove it there.

What it does not do is also worth saying plainly. Tidemark surfaces what your customers have told you. It does not generate a product strategy, and it does not make calls on your behalf. The decisions stay yours. That is a deliberate choice, not a gap we are planning to fill.

Most tools that promise to “organize your feedback” give you another place to put it. The difference with Tidemark is that every ranked item is traceable to source. You can defend the list because the list shows its reasoning.

If you have been pulling feedback from multiple places before every planning meeting, you are the person this is for.

Tidemark opens for early access on July 1 at tidemark.io. If something does not work the way you expected in your first week, the team wants to hear from you at feedback@tidemark.io - that feedback is exactly what shapes what comes next.

A personal year-end reckoning with a difficult year

This year broke me in a few specific ways, and I am still accounting for them.

The project - eighteen months of work, a team I trusted, a problem I believed in - ended in April without the outcome we needed. The product shipped. Nobody used it. I spent the summer parsing what went wrong and landed on this: I protected the vision too long. Evidence was arriving that the core assumption was off, and I kept reframing it as a validation problem. It was not a validation problem.

The relationship ended in a quieter way, which made it harder to name. Mara and I did not fight. We stopped being the same people who had started the thing. I do not have a clean read on whose fault that is, or whether fault is even the right frame. What I know is that I handled the last six months of it poorly. I was not present in the ways that mattered. I noticed this mostly after.

What the year asked of me was more honesty than I managed to give it. Not the dramatic honesty of hard conversations - though I owed some of those - but the quieter kind: looking at what I was actually seeing instead of what I wanted to see.

I am not going to call any of this a gift. It was expensive and I would not choose it. What I am choosing to carry forward is simpler: I want to be faster to name what I am actually observing. The gap between what I saw and what I acknowledged cost me this year. I would like it to cost less next time.

Appears in diff-pairs

• direct-communicator vs executive (varies voice)
• direct-communicator vs operator (varies voice)
• direct-communicator vs executive (varies voice)
• direct-communicator vs operator (varies voice)
• direct-communicator vs executive (varies voice)
• direct-communicator vs operator (varies voice)