Announcement

A direct message telling an audience about something new or changing, in the organization’s own voice.

Announcement

An announcement is a direct message that tells an audience - customers, users, a community, or a company - about something new or changing: a launch, a milestone, a policy, a change of plans. It leads with the news, explains what the change means for the reader, and closes with a clear next step. The audience is the end reader, not a journalist who will reshape the message before passing it on.

That directness is what gives the announcement its character. The tone is the organization’s own voice: human, clear, and addressed to people who have a stake in the news. There is no dateline to fix the document in a news-wire geography, no boilerplate to orient a reporter to the company’s history, and no attributed quote supplied for a journalist to lift. The writer speaks directly to the people who will act on the news.

The format’s essential structure is simple: state the news, explain what it means, and point to what comes next. That directness is not simplicity - it is discipline. A well-written announcement respects that the reader already knows the organization and wants the substance quickly, without the setup and ceremony of formats designed to survive in a newsroom.

Canonical template

[Subject line / headline: what happened, in plain language]

[Opening paragraph: the news, stated directly. What changed, launched, ended, or started.]

[Body paragraph: what this means for the reader. Specific impact, benefits, or consequences.]

[Supporting paragraph (optional): relevant context, timeline, availability, or background detail.]

[Closing: next step for the reader - what they should do, where to go, or when more is coming.]

When to use

Announcing a product launch, new feature, or availability change directly to customers or users. Communicating a policy update, pricing change, or operational change to the affected audience. Marking a company milestone - funding, partnership, or team news - addressed to the community. Notifying users or customers of a change that requires their attention or action. Delivering internal company news directly to employees when a direct, news-first format is appropriate.

When not to use

When the goal is media coverage and a journalist needs to repackage the news - use a press release instead. When the content requires extended argument, evidence, or development - use a blog post or whitepaper. When the communication is exploratory, informal, or conversational rather than news-bearing.

Pairs well with

executive, product-thinker, confident, candid, executive-summary

Often confused with

press-release: A press release is a formal external announcement in news style - with a dateline, headline, attributed spokesperson quotes, a boilerplate “About” section, and a media contact block - built for journalists to republish without needing to interview anyone. It travels through layers of reception (PR wire, editorial inbox, news desk), and its formality signals that the content is legally cleared and safe to quote as issued. An announcement addresses the affected audience directly, in the organization’s own voice, with no intermediary to persuade; it carries none of the structural signals a newsroom needs, because no newsroom is in the chain.

release-notes: An announcement is a single-subject news message in the organization’s own voice - it states a piece of news, explains what it means for the reader, and closes with a next step. Release notes are version-anchored, multi-item, and curated from a changelog into scannable grouped sections (New, Improved, Fixed) under a version identifier. Use an announcement when a single piece of news warrants a direct message to the audience; use release notes when a versioned software release has multiple changes to communicate.

Tells

• Leads with the news in the first sentence, with no preamble, scene-setting, or organizational background
• Written in the organization’s own voice, addressed directly to the reader - “you/your” phrasing is common
• No dateline, no media contact block, no boilerplate “About” section
• Closes with a concrete next step or call to action for the reader
• Minimal length: no more than what is needed to state the news and explain its impact
• Single, clear subject: one thing announced per document, not a digest or roundup

Anti-patterns

• Burying the news behind organizational context, mission statements, or founder story before stating what happened - The reader opened the announcement to learn what changed; delay signals that the writer is not confident the news stands on its own.
• Applying press-release conventions - dateline, attributed executive quotes, media contact block, boilerplate “About” section - when writing directly to an audience rather than journalists - A press release is a formal, journalist-addressed format built for newsroom intermediaries; its structural signals tell a reporter the content is cleared and ready to republish, which is not what a direct audience needs to receive.
• Ending without a next step or call to action - An announcement exists to move the reader toward a link, a date, a decision, or an action; without a closing direction, the reader is left uncertain what to do with the information.
• Announcing multiple unrelated items in a single document - An announcement has one subject; combining a product launch with a policy change and a team update diffuses the news and forces the reader to hold too many things at once.

Failure modes

• Over-hypes: the announcement tips from direct news into promotional copy, loading every paragraph with superlatives, “we’re thrilled,” and “game-changing” language until the news itself is obscured by performed enthusiasm - Check every evaluative adjective; if removing it loses no factual content, remove it. The announcement earns trust by stating the news plainly, not by performing excitement about it.
• Over-explains: the announcement pads the news with so much context, history, and background that the directness the format is built for disappears, and the reader has to work to find the actual news - Locate the sentence where the news first appears; if it is not the opening sentence, cut or move everything before it. The reader needs to understand what the change means for them, not the story of how it came to be.

Instruction

Write as a direct announcement addressed to the affected audience in the organization's own
voice. Do not use press-release conventions: no dateline, no attributed quotes for a journalist
to lift, no boilerplate "About" section, no media contact block. Open with the news in the
first sentence - no preamble, no mission statement, no background before the fact. Follow with
what the change means for the reader specifically. Add supporting detail only if it is necessary
to understand the news or act on it. Close with a clear next step: a link, a date, a decision,
or an action. Keep the length to what the news requires - 150 to 400 words is typical. State
the news plainly; do not inflate it with superlatives, "excited to announce," or promotional
adjectives that a reader would have to discount.

Template

See the Announcement template.

Related

Pairs well with

Executive, Product Thinker, Confident, Candid, Executive Summary

Avoid with

Confessional, Reverent, Skeptical

Often confused with

Press Release, Release Notes

Examples

Whether the team should move to async-first standups

The daily 9am standup is replaced with async updates in #team-standup, starting Monday.

As of Monday, the 9am Pacific standup slot is gone. Each of you posts a short update to #team-standup by 10am your local time instead. No call. No round-robin. No 9:30pm commitment for the India team.

The update template is pinned in the channel:

• Shipped: what landed since your last post
• In progress: current focus
• Blocked or at risk: what is stuck, with an @mention of whoever can unblock you

The on-call engineer scans the channel between 10am and 11am Pacific and responds to @mentions within 30 minutes during business hours. If something needs a real-time conversation, the Thursday working session at 8am Pacific / 8:30pm IST is the slot. Agenda lives in docs/thursday-agenda.md; if there is nothing to discuss, it cancels by Wednesday 5pm Pacific.

This is a 30-day trial before we lock it in. If something is not working, add it to docs/trial-retro.md rather than letting it sit in DMs.

To get started: read the pinned message in #team-standup, copy the three-field template, and post your first update on Monday morning.

Designing a sustainable morning routine

Month 2 starts today

The 30-day morning routine experiment is done. I am running Month 2 starting today, 2026-06-14.

23 of 30 mornings completed against the full four-step protocol (water, light, movement, planning). Phone deferred until step 4 on 28 of 30 days. The results are specific enough that stopping would require a deliberate choice to return to something worse, and I am not making that choice.

Three things change in Month 2:

Travel variant. Two of the three travel-day failures happened because I tried to run a home-specific protocol in a hotel and quit when the first step was not physically possible. protocol/travel.md is now live with adapted versions of each step for unfamiliar environments.

Sunday planning session. Tuesday was the hardest day of Month 1 - three of my four unexplained missed mornings were Tuesdays. A 15-minute paper-based planning session on Sunday evenings joins the weekly rhythm starting this week. The hypothesis: Monday consumes buffer that Tuesday needs.

Weekends are now a rule. I was already running the protocol on weekends. Writing it as an explicit rule rather than an improvised daily choice removes the decision on mornings when it feels optional.

The core sequence stays unchanged: water, light, movement, planning. Wake at 6:15. Phone in the kitchen until step 4.

Week-by-week retros continue in log/retros/. The Month 2 status report goes up on day 60, on or around 2026-07-13. If you have run a similar experiment and found a travel adaptation that actually works, the discussion tab is open.

Choosing Postgres vs DynamoDB for a new service

Subject: Notification Service datastore decision locked - Postgres (ADR-0023 accepted)

The notification service will run on Postgres. We locked the decision in the 11am Friday sync with Priya; ADR-0023 is now accepted.

For the team building and operating this service, here is what that means: the new notifications schema lands in the existing primary cluster, backed by a pg_notify job queue and a notification_jobs table. The 4-person on-call rotation stays on a single stack. No new runbooks, no new monitoring surface, no new debugging skillset on call.

The 5M events/day mark is the revisit threshold per ADR-0023. When we hit it, we evaluate a DynamoDB migration before scaling the Postgres path further. Until then, Jordan will have queue depth and write rate on the on-call dashboard by 2026-05-22 so we can track it.

The immediate next steps:

• Sam delivers the notifications schema and notification_jobs table spec by 2026-05-20.
• Jordan adds queue depth and write rate to the on-call dashboard by 2026-05-22.
• Target for first end-to-end internal traffic on the Postgres path: 2026-05-29.

Sprint planning starts today at 2pm. Read ADR-0023 before you arrive: docs/adr/0023-postgres-notification-service.md. Questions go to #notify-arch.

Telling stakeholders a committed feature is being cut this quarter

Insights Dashboard Moves to Q1 2027 - CSV Export Ships September 26

The Insights analytics dashboard is being removed from the Q3 commitment and rescheduled for Q1 2027. A CSV data export ships on September 26 as a stopgap while the full dashboard is under development.

The billing-system migration overran its planned timeline this quarter and consumed the engineering capacity allocated to the Insights build. Releasing the dashboard on the original Q3 date would have meant shipping it without saved-view persistence or scheduled-report delivery - the two capabilities the committed accounts specifically asked for. A partial release would have required immediate remediation and undermined credibility on future commitments. The team deferred rather than ship short.

The CSV export gives affected customers direct access to their underlying event data now. They can open the file in a spreadsheet or BI tool to filter, group by user or feature, and build the views they were waiting on the dashboard to provide. Jordan Park (customer success) is sending written notices to the four key accounts this week and scheduling individual calls with any account that flagged a strong dependency on the Q3 date.

The full in-app dashboard - with date-range selectors, per-feature breakdowns, saved views, and scheduled summary emails - is targeted for March 13, 2027. Engineering is beginning the Q1 design document on October 6, after the billing release stabilizes.

What you need to do before Thursday:

• Sales: if any of the four key accounts need a direct conversation before the written notice arrives, flag the account name to Jordan Park. Individual calls reduce the risk of the notice landing cold.
• Leadership: customer-facing outreach will reference the March 13, 2027 target. Please confirm that date is cleared for use in external communications.

Questions about the CSV export or the Q1 scope go to Maya Chen (product) or Dario Reyes (engineering).

Getting a new engineer productive in their first two weeks

Subject: Priya joins backend services on Monday, June 22 - two-week onboarding plan

Priya joins the backend services team on Monday, June 22. This message covers what the first two weeks look like and what the team needs to do before she arrives.

The onboarding follows the structured two-week guided pairing protocol from ADR-0023. Days 1 and 2 are access and tooling, owned by her named buddy with a checklist. Week one includes two guided walkthroughs - one on service topology, one on deployment and on-call tooling. Week two is a pre-scoped first change that Priya drives end to end, with Arjun pairing on the code review. Mei is the onboarding DRI and the right person to contact if anything in the plan needs adjusting.

This protocol is intentionally bounded. If you are not the named buddy, you are not responsible for managing her onboarding day-to-day. If you own a service in the ownership doc, expect a one-on-one request from Priya sometime in week one - a thirty-minute conversation is the right response. The full onboarding guide lives in the backend services repo.

Priya is excluded from the on-call rotation for her first thirty days. Her first pull request is targeted for the week of June 29.

If you have access or provisioning requests to submit for Priya, use the IT portal before end of day Friday so credentials are ready Monday morning. Questions about the plan go to Mei.

Writing to thank a mentor who shaped your career

I owe Dana Forsythe a public acknowledgment I have been slow to write.

Dana nominated me to lead the Alderton platform migration in March 2016. I told her I was not ready. She nominated me anyway.

That is the news. This is not a career retrospective or a management lesson. It is a direct acknowledgment of a specific debt.

What Dana did was costly in practice, if simple in description. She put my name forward when the safer call was to name someone with an existing track record at that scope. She stayed close through the first months - available for questions, willing to ask sharper ones back - and did not take over when taking over would have been faster than watching me find my footing. The project shipped. By the following spring I had an enterprise migration on my record and a durable belief that I could lead something I had not done before. Both have continued to compound.

I understood what that cost her only recently, when I put Priya Osei forward to lead the Cassava data-pipeline rebuild in February. In week three, when Priya was stuck on a handoff problem, I sat on my hands instead of solving it for her. The moment I recognized what I was doing, I understood where I learned to do it - and what it took from Dana to stay patient when I was the one who was stuck.

If you have someone like Dana in your professional history, this is an invitation to name them before another decade passes. If you are in a position to be Dana for someone on your team: the method is one sentence - put them forward before they feel ready, and do not take over while they find their footing.

Dana, thank you. The pattern has been passed forward.

Reflecting on keeping a discipline of rest

Sundays Are Now Offline

Starting this week, I am keeping one full day each week away from work, messages, and notifications. Sundays are that day. If you send something on a Sunday, you will hear from me on Monday.

This has been the pattern for fourteen weeks. It is working well enough that I am treating it as settled rather than experimental, which is why it is worth naming directly: Sunday availability that you may have counted on is no longer there.

What changes for you: anything time-sensitive should arrive by Saturday afternoon. If something is genuinely urgent - the kind that cannot wait until Monday morning - call. For everything else, Monday morning is when I return to messages.

The six days I am available carry more quality than they did when I was available all seven. I did not expect that when I started, and I mention it not to explain myself but because it is relevant information if this pattern affects how we work together.

If the timing creates a problem worth discussing, reply here and we will figure it out.

Marking a long-serving colleague's departure

Howard Thayer is retiring after twenty-six years - please join us today to say goodbye

Howard Thayer’s last day at Crestfield Group is Saturday, June 27. Today at 3:00 p.m., we are holding an all-hands send-off to mark his twenty-six years as Operations Coordinator and to give everyone a chance to say goodbye in person.

Howard joined Crestfield in June 2000 and held that role for his entire tenure. Over those twenty-six years, he became the person the team called when the situation was genuinely unclear - not because he had the loudest opinion, but because he had been there before. He carried vendor contacts, incident history, and institutional context that existed nowhere else in our systems. He also mentored colleagues through difficult early careers, without keeping score or taking credit.

His departure creates a real knowledge gap. Dana Reyes and Marcus Okonkwo have taken ownership of the operational handoff, and Howard spent May and June working with them to document the informal decision trees, vendor escalation paths, and contact lists he maintained for two decades. That knowledge is now transferred and written down. What is not transferable is the pattern recognition and steady presence Howard brought to twenty-six years of novel situations. The team will feel that absence when it matters most.

Join us today at 3:00 p.m. in the main conference room. Remote link is below. If you cannot attend, Howard’s last day is Saturday, June 27 - send him a note before end of day.

[Remote join link]

Marking the team shipping a hard, long project

Project Halyard shipped on June 13. The rebuilt checkout is live for all users.

The first peak weekend passed without incident. No latency spikes. No rollbacks. Cart completion held at the targets the team set in January.

This was fourteen months of work that was mostly invisible to the rest of the organization. The team ran the new checkout in parallel with the old one, migrating traffic by cohort from a 1% canary up through the full ramp, while keeping the legacy flow live and maintained at every step. No user ever encountered a degraded checkout during the migration. The old system moved to archive mode at cutover and decommissions July 14.

Two serious issues surfaced before go-live. A cart-state mismatch that would have corrupted multi-item orders under split payment (February) and a payment-callback race condition caught in the final dress rehearsal (April). Both required weeks of additional work and pushed the launch date back. Both were found by engineers reading the data carefully enough to notice something was wrong, not by the automated test suite.

The people who held this together: Priya Vasquez led the program. Dani Rowe called the hold on the March launch when the pressure to ship was real and the issue was not fully resolved. Marcus Teel filed the February bug when marking it low-severity and moving on was an option. Jordan Osei rewrote the payment callback handler when a smaller patch was available and tempting. Sam Wickfield held the regression bar on June 9 under real pressure to ship. Yuki Tanaka kept two slip decisions from turning into a schedule collapse. Ket Osei ran the final cutover during peak load.

The first post-launch cart-abandonment baseline is due July 7 from the analytics team. For questions about the new checkout API or the v1-to-v2 migration path, see the migration guide in the engineering wiki or drop a message in the engineering channel.

Arguing a public position on return-to-office

Subject: Our new work location policy - anchor days on Tuesday and Thursday, starting August

Starting in August, we are moving to a structured hybrid schedule: Tuesday and Thursday are anchor days, and Monday, Wednesday, and Friday are fully flexible.

If your role is office-eligible and you can physically reach an office, you are expected to be in one on Tuesdays and Thursdays. The other three days are yours to locate however your work calls for it - no approval required, no check-in. You decide where you work based on what you have on your plate that day.

This policy reflects a deliberate position. In-person time is most valuable when it is predictable and shared; anchor days make it both. The fully flexible remainder is not a concession to distributed work - it is a recognition that focused work is often done better without a commute. The structure holds both of these things at once rather than trading one off against the other.

Before August, a few things to know. Employees hired as remote-eligible are not subject to the anchor-day requirement; your arrangement stays as documented at hire. Exceptions to the Tuesday and Thursday schedule require documentation, reviewed by your manager and the people team. Facilities will update room-booking to reflect anchor-day capacity priorities before the policy takes effect.

The Manager FAQ covering anchor-day logistics, accommodation requests, and new-hire onboarding is available now on the internal HR portal. Questions not answered there go to the people team directly or to the all-hands Q&A session.

Announcing a new product to an outside audience

Tidemark is now available

Tidemark launched publicly today. If your team has been collecting customer feedback across spreadsheets, chat threads, and ticket trackers with no single view of what matters most, Tidemark connects those sources, surfaces recurring themes, and scores them by frequency and recency - giving you a ranked, shareable roadmap.

For most small product teams, pulling feedback together means someone manually reading everything, copying items into a spreadsheet, and debating priority in a meeting. Tidemark handles the consolidation automatically. After a short setup, you can see what customers are actually asking for in minutes and share a read-only ranked view with any stakeholder who needs it.

Tidemark is available in three plans. A free solo plan is open with no time gate. Team plans are $29 per month for up to 15 seats. Organizations that need SSO and audit logs can contact us about a custom plan.

Sign up at tidemark.io. If you want to see the product before committing, there is a 20-minute walkthrough available on the same page - no sales call.

A personal year-end reckoning with a difficult year

The Meridian project closed in March. This is where things stand at the end of the year that held it.

In March 2025, Meridian ended when the primary funder withdrew. Eighteen months of work, eleven contributors, and no public launch. I am not writing this to relitigate the decision - the closure was not mine to control. I am writing this because the people who gave time to Meridian are owed a clear account of what happened and what I am doing next.

The second thing that happened this year: a close friendship changed shape in ways neither of us fully chose. By August the distance was clear. I kept waiting for it to close on its own. It did not. I am carrying both of these at the same time, and I am not always certain which one I am sitting with on a given day.

What I got wrong: I managed optimism inside the Meridian coalition longer than was honest. I was protecting the project. What I was actually doing was delaying a reckoning that arrived anyway, with less trust intact. I also kept the friendship at arm’s length during the months the project was under the most pressure. I told myself that was composure. It read as absence.

Here is what comes next. I am writing a full retrospective for the Meridian contributors, targeted for February. If you were part of that work, it is coming to you directly. I am also answering a message I have been avoiding since April. Both of those things happen before I start anything new.

This year is closed. Those are the next two tasks.