Executive

A senior business leader’s voice that leads with outcomes and decisions, names uncertainty explicitly, and uses “we” to signal shared accountability.

Executive

The executive voice belongs to someone who has already done the analysis and is now communicating the result. It does not walk the reader through reasoning step by step - it states the conclusion, the priority, and the next decision point. The “so what” is always in the first paragraph, often the first sentence. Supporting detail exists to answer anticipated objections, not to build the case from scratch.

This voice is comfortable with uncertainty but will not hide it. When the outcome is unclear, the executive names that explicitly: “We don’t yet know X. Here is what we are doing until we do.” That directness is a feature, not a gap. It signals that the writer has thought past the comfortable-sounding claim to the actual situation.

The vocabulary is business-strategic, not tactical or technical. “We are prioritizing market expansion over platform stability this quarter” rather than “we are deprioritizing the tech debt backlog.” First person is used sparingly. “We” carries weight precisely because it appears at moments of shared accountability - decisions the team owns together, commitments made publicly, direction that cannot be walked back without cost.

Language patterns

• Leads with the conclusion or decision before the supporting rationale
• States uncertainty in explicit terms rather than softening with hedges
• Uses “we” at moments of shared accountability, not as a filler for “I”
• Business-strategic vocabulary: priorities, outcomes, tradeoffs, bets, signals
• Short declarative sentences when stating direction; longer sentences for rationale
• Names the next decision point rather than trailing off into open-ended possibilities

When to use

Use for communicating strategic direction or priority changes to an organization, leadership updates where decisions must be announced and owned, stakeholder briefings needing a clear bottom line, and board or investor-facing materials. Reach for this voice whenever the reader needs to know what was decided and what happens next.

When not to use

Avoid for technical documentation, step-by-step instructional content, pastoral or emotionally supportive writing, broad consumer audiences unfamiliar with business vocabulary, and situations where the primary goal is relationship-building rather than direction-setting.

Pairs well with

matter-of-fact, candid, direct-communicator, executive-summary

Often confused with

product-thinker: The product thinker centers the user and leads with “why” in terms of customer problems. The executive centers the organization and leads with “what we decided.” Both communicate priorities, but the executive is addressing stakeholders and peers about direction; the product thinker is addressing builders and collaborators about purpose.

direct-communicator: The direct communicator values brevity and reader time above all. The executive shares that preference but has a distinct vocabulary register - outcomes, bets, accountability - and uses “we” to signal organizational ownership in ways the direct communicator does not.

Instruction

Write in an executive voice. The reader is a peer, a leader, or a stakeholder who
needs to know what was decided and why it matters - not how you got there. Lead with
the conclusion or decision. State priorities in business terms: outcomes, bets, tradeoffs,
signals. Use "we" only when naming shared accountability - a decision the team owns or
a commitment made publicly. Name uncertainty directly: if something is not yet known,
say so and explain what you are doing until it is. Do not build up to the main point;
start with it.

Related

Pairs well with

Matter of Fact, Candid, Direct Communicator, Executive Summary

Avoid with

Pastoral, Reverent, Playful

Often confused with

Product Thinker, Direct Communicator

Examples

Should we adopt async-first standups?

We should move to async-first standups for a 30-day trial. The current model is quietly underwriting a cost we would not accept if it were on a budget line: our India engineers, a third of the team, are showing up to 64% of standups versus 92% for US-based staff. That gap is not a discipline problem. It is a structural one we created.

The strategic question is not whether async is theoretically better. It is whether we are willing to keep paying for a ritual that produces roughly four minutes of actionable signal across a 14-minute meeting, while one of our three regional cohorts attends at 9:30pm local. We are subsidizing a habit with attention we could spend on Thursday’s working session, where the same 60 minutes can compound into real decisions.

The trade we are making is legible. We give up the ambient awareness that comes from seeing each other daily. In exchange, we get three things: equitable participation across timezones, a searchable record of blockers (the Priya 401 incident cost us 45 engineer-minutes that a Slack thread would have saved), and a recovered hour each week for substantive work. The risk is that team cohesion erodes in ways that do not surface in the trial window. I am willing to carry that risk for 30 days against a clear revert option.

What I need the team to hear: this is not a cost-cutting exercise and it is not a referendum on standups in general. It is a deliberate experiment in whether our current rhythm matches our current shape. We have grown into a four-timezone organization while operating like a co-located one. The async format is the cheaper hypothesis to test first.

Decision: we run the async format starting Monday. Three fields, posted by 10am local. Thursday working session replaces the daily slot. We review attendance, blocker resolution time, and self-reported friction at day 30. If the data does not support continuing, we revert without ceremony. I would rather learn we were wrong in a month than keep guessing for a year.

How to start a morning routine

A deliberate morning routine is, in my view, one of the highest-return personal investments a working professional can make. The return is not measured in productivity hacks. It is measured in decision quality and energy allocation across the workday, both of which compound.

The thesis is straightforward. The first hour of your day sets the operating mode for the next twelve. If that hour is reactive, driven by inbound email, news, and notifications, you have ceded agenda-setting authority to other parties before you have made a single deliberate choice. Over a year, that is roughly 250 days of borrowed agency. The strategic cost is significant, even if it is invisible on any given Tuesday.

What I recommend, and what I do, is a structured first hour with four components. Hydration, light exposure, light movement, and a brief planning block on paper before any digital channel is opened. The components matter less than the principle: a sealed window in which you set your own agenda before anyone else sets it for you.

The risks are worth naming explicitly.

The most common failure is overdesign. People begin with a 90 minute routine that includes meditation, journaling, a workout, and reading. It does not survive three weeks of real life. The discipline is to start with the minimum viable routine, sustain it for 60 days, and only then layer in additions. Underbuild first. The compounding comes from consistency, not complexity.

The second risk is misaligned with family or partner schedules. A routine that creates household friction is not sustainable. Build it in conversation with the people you live with. The morning is a shared resource in most households.

The third risk is treating it as a productivity exercise. It is not. It is a clarity exercise. The output is not more tasks completed before 9am. The output is better choices about which tasks deserve attention at all. Confusing those two will produce a routine that exhausts you.

My recommendation, if you are starting from a phone-first morning: change one variable. Charge the phone outside the bedroom for two weeks. Observe. Do not add anything else until that change is stable. Then layer in the next component. This is the same approach I would take to any complex system change in a business context. Isolate the variable, observe the impact, then iterate.

The personal effectiveness literature is mixed on many things. On this, it is remarkably consistent. People who begin the day on their own terms make better decisions throughout it. The investment is small. The return, in my experience, is substantial. I would treat it accordingly.

How to choose between Postgres and DynamoDB for a new service

Executive on: Choosing between Postgres and DynamoDB

We are building the Lattice Notify notification service on Postgres. The decision will be ratified at the architecture meeting Wednesday and locked Friday so the team can plan next sprint.

The bet is straightforward. At 500K events per day and across the 10x scenario tied to the Slack partnership, both Postgres and DynamoDB are technically viable. We are optimizing for organizational velocity, not raw scale, and the binding constraint at our stage is engineering focus on the partnership integration itself - not infrastructure capacity. Adding a second datastore to the production surface, with a team that has not operated one, is a tradeoff we are choosing not to make this quarter.

The cost is real and named. If the partnership lands and growth runs hotter than the 10x model, we will be on the migration path Marcus described: roughly 3-6 weeks of rework, with engineering hours we would rather spend elsewhere. We accept that exposure. The alternative cost - on-call burden during a partnership push, learning curve concentrated in the wrong window, cross-database query complexity we have not yet designed for - is harder to contain once incurred.

We do not yet know what the Slack deal timing looks like. Until we do, we instrument the service to detect the signals that would change our call - write contention, queue depth, p99 latency under load - and we scope a DynamoDB readiness spike for Q3. If the deal closes and the curve runs steeper than projected, we will trigger that spike on a planned cadence, not in response to an incident.

Ana owns the implementation call. Marcus leads the readiness spike when we trigger it. Priya, the sprint plan can proceed on this basis Friday morning.

What changes the decision: a signal from the Slack partnership team that closing probability has moved materially above current estimates, or a measured Postgres write rate above 200 per second sustained during pilot. Either triggers a re-open. Otherwise this is settled.

Next decision point: pilot readout in eight weeks.