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.

Tells

• Leads with the conclusion or decision before any supporting rationale
• The “so what” is in the first paragraph, often the first sentence
• Business-strategic vocabulary: priorities, outcomes, tradeoffs, bets, signals
• Uses “we” at moments of shared accountability, not as filler for “I”
• States uncertainty explicitly (“we do not yet know X; here is what we are doing until we do”)
• Names the next decision point rather than trailing into open-ended possibilities
• Short declarative sentences for direction, longer constructions only for rationale

Anti-patterns

• Walking the reader through the full analysis before stating the decision - The voice communicates a result already reached; rebuilding the case from scratch buries the conclusion the reader needs first.
• Leading with the customer problem and the job to be done - That is the product-thinker orientation; the executive centers the organization and what was decided, not the user purpose behind it.
• Softening genuine uncertainty with vague hedges instead of naming it - The voice treats explicit uncertainty as a feature; hiding it behind comfortable-sounding language signals the writer stopped short of the real situation.

Failure modes

• Tips into decree, stating direction so flatly that it reads as unaccountable fiat - Reserve “we” for genuine shared ownership and name the next decision point; authority comes from owning the call, not from clipping all context.
• Over-abstracts into strategic vocabulary until the actual decision is vague - Make the bet concrete (“prioritizing X over Y this quarter”); business framing should sharpen the call, not dissolve it into buzzwords.

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.

Telling stakeholders a committed feature is being cut this quarter

We are moving Insights out of Q3. That is the decision, and it is not a close call.

The billing-system migration ran over its window by six weeks. It was a non-negotiable regulatory obligation, and the team had to complete it; there was no path that preserved the Insights timeline and also shipped a compliant billing system by December. The engineering capacity we had reserved for Insights went to the migration. We assessed the remaining options: ship Insights on the original date in an incomplete state, or hold the release until the feature is built right. Shipping a half-built dashboard to customers who were specifically promised Insights would cost more in credibility than this delay does. We chose to hold.

Insights ships in Q1. We do not yet have a specific date within the quarter; that scope confirmation closes in October. What is not uncertain is Q1 itself. That is the commitment we are making today.

This quarter, we are shipping a CSV export of the underlying analytics data. It is not the dashboard. We are not framing it as a substitute, and you should not either. It gives customers direct access to the same data Insights will surface, so they can work in their own tools through the gap. It ships before the end of this quarter.

Two asks. First, when you communicate this to customers, lead with Q1 and the CSV export together. The delay lands differently when the bridge is visible. Second, if any account is at a renewal decision where Insights was a named commitment, bring it to us now. We need that information before the customer conversation happens, not after.

The tradeoff we made - billing infrastructure over a promised feature - is ours to own. What we owe you now is a clean path forward and early visibility when anything changes. You have both.

Getting a new engineer productive in their first two weeks

Priya is our priority for the next two weeks. The goal is one shipped change in production by end of week two - not a tutorial exercise, a real change. Everything else in the onboarding plan exists to make that outcome achievable.

We are running the two weeks in two distinct phases. Phase one is entirely about eliminating friction: access provisioned, tooling configured, the architecture understood well enough that she is not guessing at the shape of the system. She does not need to have read every service by Friday - she needs to know where to look and who to ask. Phase two is about doing real work with a pairing partner. We are matching her with someone who knows the codebase well. That pair will identify and ship a bounded, low-risk change together. The choice is deliberate: the goal is a successful first deployment, not an impressive first ticket.

We do not yet know which change that will be. We will know by Wednesday of week two, once Priya has enough codebase exposure to weigh in on where she can contribute. Let the context drive the pick, not the ticket tracker.

On-call is a signal, not a burden. Priya stays off the rotation through week four, but she walks through runbooks and incident history in week one. She should understand the system’s failure modes before she is accountable for them. The risk we are accepting is one less body on rotation for a month. The bet is that a well-oriented engineer on week five outperforms a rattled one on week two.

Belonging is not a bonus outcome - it is a delivery condition. By end of week two, Priya should have a shipped change, a pairing partner she trusts, and a clear picture of who owns what.

The next decision point is end of week one. By then, we should have a candidate change in view and Priya should be clear on the deployment pipeline. If either is not true, we adjust before week two starts.

Writing to thank a mentor who shaped your career

Dana,

The reason I’m writing is this: last month I put one of my direct reports forward for a scope she did not feel ready for, and within two weeks I recognized that I had borrowed the playbook from you.

You made that call on me about ten years ago. The project was a cross-functional launch - more visibility, more stakeholders, more exposed surface area than anything I had carried before. I told you I wasn’t sure I was the right bet. You disagreed, and you put me in. What I did not fully reckon with at the time was the cost on your end. You stayed close enough that I was never actually alone in that first hard stretch, but you did not step in. That is a harder line to hold than it sounds. Taking over is faster, lower-risk, and easier to justify. You chose the slower path, and that patience had a price.

The outcome it made possible is not separable from that tradeoff. I learned something you cannot teach in a debrief: what it feels like to carry weight that is actually yours, without a safety net that makes it notional. That lesson transferred. When I made the call on my direct report last month, I knew exactly what I was asking her to hold, and I knew what staying close without taking over actually requires.

I don’t know what I cost you in re-work or anxiety during those months. I probably still underestimate it. What I can say clearly is that the bet compounded. It is paying out now in someone else’s growth, which means you are further downstream in this outcome than you could have planned for, but you are in it.

That felt worth naming explicitly.

Reflecting on keeping a discipline of rest

The bet: one day a week belongs to rest, and I am holding that line even when the cost feels real.

That is the decision I made after enough failed attempts to count as data. The pull to check one more thing, to close one more loop before the day is truly off - I know that pull well. For a long time I let it win. The result was not more output; it was shallower recovery and a steadily narrowing capacity to do the work that actually matters.

Now I treat the day off as a non-negotiable output constraint, the same way I treat a board meeting or a hard deadline. The tradeoff is explicit: I am trading the feeling of control on that one day for something harder to measure but easier to name. Clarity. Steadiness. The ability to think at the level the week actually requires.

What I did not expect is how much the rest day reorders the surrounding six. The signal it sends - to my own system, to the people I work with - is that I am playing a longer game. A leader who cannot set the device down is not modeling sustainability; they are modeling depletion.

The next test is whether I can make this a policy rather than a discipline. Disciplines erode under pressure. Policies have a rationale that survives the hard weeks.

I do not yet know if I will hold this standard when the pressure spikes hard enough. That is the honest read. What I can say is that the quarters where I have protected that day have returned more than the quarters where I treated rest as overhead.

Marking a long-serving colleague's departure

Howard Brennan retires Friday. The honest read on what that means: this organization is losing something that does not appear on any reporting line.

Twenty-six years in the same role is not a career plateau. It is a sustained organizational bet that paid out repeatedly. Howard chose depth over advancement, and we benefited from that choice every time a critical system went sideways at midnight, or a client relationship needed someone who remembered why the original call was made. The ticket tracker still carries requests he filed in the early years, written in the same measured cadence he used last week. That continuity was never budgeted for. It was simply there.

What we are losing is harder to inventory than a headcount. Howard was the first call when someone joined the team and did not yet know enough to be dangerous. He is the reason at least four careers here exist in their current form - not because he lobbied for anyone, but because he sat down, asked the right questions, and gave the person enough room to find the answer themselves. He claimed no credit for it. That was not modesty; it was discipline.

We do not yet know how we will absorb the gap he leaves. Some of it is institutional memory that will surface only when we need it and he is no longer here. Some of it is a stabilizing function he performed without a mandate, a metric, or a formal designation. The honest answer is that we will not fully know what he held until the first crisis we navigate without him.

What we do know: Howard set a standard for how an organization can be served by someone who prioritizes the work over the recognition. That standard does not retire with him. The next decision is ours.

Marking the team shipping a hard, long project

The Apex platform team shipped the checkout rewrite last Thursday. After fourteen months of parallel operation, the new flow is live, the old one is dark, and the cart-abandonment trend that has cost us growth for three years is moving in the right direction. That is the result. The rest of this note is about what it cost.

This was not a project that looked hard from the outside. It looked like a migration. From the outside, most of what the team shipped was invisible - a new system running quietly alongside the old one while paying customers never noticed. That invisibility was the design requirement, and it made the work harder, not easier.

Two near-misses tested the bet we made to keep the live system untouched during the rebuild. In October, Priya Naledi identified a data-consistency window that would have corrupted order state for the highest-traffic segment. The team did not ship that week. That call was right, and it cost the team a launch date they had earned. Marcus Osei made the same kind of call in March, recommending we delay the full rollout after load patterns from the spring campaign came in differently than our models predicted. We did not yet know whether the new flow would hold. We held the launch until we did.

The final rollout last week cleared peak load on day one. It held.

Fourteen months is longer than we planned. Two slips is not a record we are proud of. And we are honest that the gains we are seeing are early signals, not a confirmed outcome. We will have clearer data by end of quarter.

What I want the organization to understand is that this team carried a decision tree no one else had to carry - production risk, timeline pressure, and technical bets held in parallel for over a year. They made the right calls at the moments that mattered. That deserves to be on the record.

Arguing a public position on return-to-office

The Hybrid Bet: Why We Are Committing to Anchor Days

Our position on remote work is set: a structured hybrid with shared anchor days for collaboration, and real flexibility for everything else. This is not a split-the-difference compromise. It is the bet we are making on where the return on in-person time is highest and where it is not.

The office-first case is sound, and we are not ignoring it. Trust accumulates in shared physical space. Unplanned conversations - the hallway exchange, the whiteboard session that started as a quick question - produce outcomes that are genuinely hard to schedule and nearly impossible to replicate through a chat tool. We are anchoring on that signal by designating two days each week when people are expected in together. Those days are not optional attendance windows. They are the shared commitment that makes the rest of the flexibility possible.

The fully-remote case is also sound. Requiring five days in office in a market where talent is distributed makes us a smaller organization than we need to be. The commute hours we return to people are real hours: recovered capacity that flows back into focused work. We are not pretending that in-person time is free. It is a deliberate cost we accept on specific days because the collaboration value justifies it. On other days, it does not.

We do not yet know whether two anchor days is exactly right. We will evaluate at the six-month mark against signals we can actually observe: whether collaboration quality holds, whether the talent pool has expanded, and whether people are working within the structure or around it. The last signal matters most. If people are finding workarounds, the structure is not working and we will adjust.

The next decision is implementation: which days, how we handle time zones, and what “in office” means for roles that are structurally remote. We will finalize that within three weeks.

Announcing a new product to an outside audience

We are launching Tidemark next week. The product is a ranked-roadmap tool for small teams: it takes scattered customer feedback from wherever your team collects it and produces a single prioritized list you can share with anyone who needs to understand what you are building and why.

The market we are entering has no shortage of tools, but the tools that exist are built for organizations with product operations teams and dedicated tooling budgets. We made a different bet. Tidemark is sized for the team where one person owns the roadmap, has customer feedback living in a spreadsheet, a chat tool, and a ticket tracker simultaneously, and needs to consolidate it in an afternoon, not a quarter.

We are prioritizing speed and shareability over feature depth in this launch. Some integrations are not here yet. That tradeoff is deliberate: the core workflow - gather, rank, share - has to work cleanly before we layer on connectors that add surface area and maintenance overhead. The integrations will follow. The order matters.

What we do not yet know is where the highest-value use case lands: the solo founder running a SaaS product, or the internal team lead managing a product line inside a larger organization. Both fit the profile. We will have clearer signal within sixty days, and we will update our priorities based on what we learn.

The next decision point is the pricing gate. We are launching with a free tier and a paid tier. If early usage shows the free tier is not producing the conversion signal we need to sustain the product, we will narrow it. We are not hiding that possibility.

Tidemark is available at tidemark.io starting next week. If your feedback process currently lives in three tools at once, that is the problem we built this to solve.

A personal year-end reckoning with a difficult year

The year delivered two significant failures, and I am not going to describe them as growth opportunities. A project I had staked twelve months of effort on closed without the outcome I had bet on. A relationship that had been genuinely important to me changed in ways I did not choose. I am writing this to account for both clearly, not to resolve them into a more comfortable story.

The project failure was in significant part mine. I had seen signals of drift early and chosen to hold position rather than adapt. That decision was explicit. I owned it in the room and I defended it when it was questioned. It was wrong. Looking back, I was optimizing for the outcome I wanted rather than the one the situation was actually offering, and I held that position well past the point where the evidence supported it.

The relationship is harder to account for. Marcus and I built something that mattered, and then we did not. What I know is that we communicated well when things were stable and poorly when the stakes were highest. The gap between what I said and what I meant grew until it cost us more to close than we could agree to pay. I do not have a clean read on how much of that was circumstances and how much was accumulated failure on both sides. I am not pretending to.

What I am choosing to carry forward: a shorter timeline for naming a problem before it compounds, and a genuine skepticism of positions I find myself defending primarily because I invested in them. The next question I am actually sitting with is what I am prioritizing now - not as recovery, but as a real recalibration of what I am willing to bet on.

I do not know yet whether I am getting that right. That is the honest signal.

Appears in diff-pairs

• executive vs direct-communicator (varies voice)
• executive vs product-thinker (varies voice)
• executive vs senior-consultant (varies voice)
• executive vs direct-communicator (varies voice)
• executive vs product-thinker (varies voice)
• executive vs senior-consultant (varies voice)
• executive vs direct-communicator (varies voice)
• executive vs product-thinker (varies voice)
• executive vs senior-consultant (varies voice)