Public Statement
An organization’s official written position on a matter of public concern, written for a watching audience.
Public Statement
Section titled “Public Statement”A public statement is an organization’s or leader’s official written position on a matter of concern - a controversy, a crisis, a decision under scrutiny. It speaks for the institution, chooses its words for a watching audience, and takes a clear position while acknowledging what it must. The audience is not the press or an internal team; it is the public, including those who may be affected by what the organization did or failed to do.
The format’s central task is accountability. Its structure follows from that purpose: open by identifying who is speaking and what they are speaking about, acknowledge the situation the audience already knows about, state the organization’s position directly, describe what is being done, and close with a commitment. Unlike a legal brief or an internal memo, the public statement is addressed to those who have standing to demand an answer - and the format signals that the organization understands this.
Unlike a press release, which proactively announces newsworthy developments to journalists in a standardized broadcast format built to travel from source to journalist to audience, a public statement is usually reactive: it responds to a situation the audience already knows about, and its job is to address concern and establish accountability, not to generate coverage. It does not need a dateline, an inverted pyramid structure, or a media contact block. Its measure of success is not republication - it is credibility with the people who are watching.
Canonical template
Section titled “Canonical template”[Organization Name] - Statement on [Topic/Situation][Date]
[Opening paragraph: The issuing entity's clear position on the matter in 1-2 sentences.No setup. State the position, not the background.]
[Acknowledgment paragraph: What the organization understands or acknowledges about thesituation. What occurred, what was known, what concern or harm resulted. Be accurateand specific; do not minimize.]
[Response paragraph: What the organization is doing or has done. Name concrete steps,responsible parties, and where possible, timeline. This is where accountability becomesaction, not language.]
[Closing paragraph: The organization's commitment going forward, what the audienceshould expect, or a clear statement closing the organization's position on this matter.]
[Signatory Name][Title][Organization]When to use
Section titled “When to use”Responding to a controversy, incident, or crisis that is already known to the public. Issuing an official position on a contested or sensitive decision the organization made. Acknowledging harm, error, or failure and communicating what the organization is doing about it. Setting the institutional record straight after misinformation or mischaracterization circulates. Responding to sustained public or media pressure with a durable, on-the-record position.
When not to use
Section titled “When not to use”Announcing a new product, milestone, or partnership - that is the job of a press release, which is built to proactively generate coverage of new developments. Internal communications where the audience is employees or stakeholders rather than the public. Thought leadership, opinion, or advocacy that makes a sustained argument rather than stating a position on a known matter.
Pairs well with
Section titled “Pairs well with”executive, senior-consultant, diplomatic, resolute, executive-summary
Often confused with
Section titled “Often confused with”press-release: A press release is a standardized broadcast format built to travel from source to journalist to audience; its discipline is the inverted pyramid, and its conventions (FOR IMMEDIATE RELEASE header, dateline, attributed quote, boilerplate “About” section, three-hash closing marker) exist to make the document safe to quote and republish without a follow-up call. A public statement does none of this - it does not seek coverage, does not follow inverted pyramid order, and carries no media contact block. The press release proactively announces; the public statement reactively responds.
incident-report: An incident-report is for a technical service disruption with a reconstructable timeline and root cause (Status, Timeline, Root Cause, Resolution); its audience is the population of affected customers who need to know what failed and what the organization is committing to fix. A public-statement covers a controversy or decision under scrutiny that has no incident timeline and is carried as institutional prose with a named signatory addressed to a watching public rather than a population of technically affected service users.
- Opens with the issuing entity - organization name or leader name - identified in the first line or first sentence
- States the position or stance in the opening paragraph without setup or background first
- Acknowledges the situation or concern the audience already knows about before explaining the response
- Uses precise, legally considered language that does not over-commit or under-commit beyond what is known
- Closes with a named signatory (name, title, organization) authenticating the statement on the record
- No inverted pyramid, no dateline, no media contact block, no FOR IMMEDIATE RELEASE header
- No promotional language or calls to action; the goal is accountability, not coverage or persuasion
Anti-patterns
Section titled “Anti-patterns”- Using hedged, non-committal language throughout so that no actual position emerges - The format exists to establish the organization’s accountability position; a statement that appears to respond while saying nothing substantive invites further scrutiny and signals the organization is hiding behind form.
- Adding a dateline, inverted pyramid structure, and media contact block to generate press coverage - A press release is a standardized broadcast format built to travel from source to journalist to audience; a public statement responds to a situation the audience already knows about and addresses concern rather than announcing news. Applying press-release conventions collapses this distinction and signals the writer misunderstands the register.
- Leading with explanation or self-justification before acknowledging the concern or situation - Opening with defense signals that the organization’s priority is its own reputation, not the people or concern at stake; the statement loses credibility before it establishes a position.
- Issuing the statement as a preemptive move when no public concern yet exists - A public statement that responds to nothing draws attention to a problem the audience did not know about or signals manufactured concern; if there is no existing public matter to address, a press release or an internal communication is the right format.
Failure modes
Section titled “Failure modes”- Over-commits to accountability - every sentence becomes an admission or an apology, the statement accumulates qualifications until it reads as a comprehensive confession rather than a considered position, and the organization loses credibility by taking responsibility for things it did not do or cannot know - Accountability means owning what the organization knows to be true; review each admission and ask whether it is supported by confirmed facts; remove or qualify anything that goes beyond what can be stood behind on the record.
- Over-measures diplomatic register - the statement becomes so careful about offending no one that it takes no real position; the language is polished but empty, and readers leave with no clearer understanding of where the organization stands - Diplomatic writing is not non-committal writing; after drafting, write the organization’s position in one plain sentence - if the statement does not support that summary, rewrite the opening until it does.
- Over-formalizes institutional voice - the statement accumulates procedural references, passive constructions, and legal-filing language until the human accountability the format is meant to establish disappears behind institutional machinery - Read the statement aloud and flag any sentence the signatory would not say in person to someone affected; formal language is appropriate, but the signatory must remain recognizable as a human being taking a position, not an institution evading one.
Instruction
Section titled “Instruction”Write as a public statement - an organization's or leader's official written position on a matterof public concern or controversy. Open by identifying the issuing entity and the situation beingaddressed; do not bury the organizational position behind setup or background. Acknowledge theconcern or situation the audience already knows about before explaining the organization'sresponse. Take a clear position in precise, diplomatically considered language - hedge only wherethere is genuine factual uncertainty, not to avoid accountability. Do not add a dateline,inverted pyramid structure, or media contact block; those conventions belong to a press release,which proactively announces news to journalists for republication. Close with the signatory'sname, title, and organization. The measure of success: a reader can state the organization'sposition in one sentence after reading.Template
Section titled “Template”See the Public Statement template.
Related
Section titled “Related”Pairs well with
Section titled “Pairs well with”Executive, Senior Consultant, Diplomatic, Resolute, Executive Summary
Avoid with
Section titled “Avoid with”Playful, Confessional, Reverent
Often confused with
Section titled “Often confused with”Press Release, Incident Report
Examples
Section titled “Examples”- Whether the team should move to async-first standups
- Designing a sustainable morning routine
- Choosing Postgres vs DynamoDB for a new service
- Telling stakeholders a committed feature is being cut this quarter
- Getting a new engineer productive in their first two weeks
- Writing to thank a mentor who shaped your career
- Reflecting on keeping a discipline of rest
- Marking a long-serving colleague's departure
- Marking the team shipping a hard, long project
- Arguing a public position on return-to-office
- Announcing a new product to an outside audience
- A personal year-end reckoning with a difficult year
Fernbridge Software - Statement on Engineering Standup Scheduling
Section titled “Fernbridge Software - Statement on Engineering Standup Scheduling”June 11, 2026
Fernbridge Software is committed to running a distributed engineering team where every time zone has an equal opportunity to participate in how we work. Our former daily standup meeting did not meet that commitment, and we have changed it.
For the past 18 months, our daily engineering standup was held at 9am Pacific, which fell at 9:30pm for the three engineers on our team based in India. This has been raised in public reviews and posts by current and former team members, and it deserves a direct answer. Our own attendance data confirms what those accounts described: over the first quarter of this year, our India-based engineers attended an average of 3.2 of 5 standups per week, compared to 4.6 for our US-based engineers. That gap was not a measure of engagement. It was a measure of the hour we were asking people to show up at.
We began a 30-day trial of an asynchronous standup in place of the daily meeting. Engineers now post a written update to a shared team channel by 10am in their own local time, covering what shipped, what is in progress, and what is blocked, and tagging whoever can resolve a blocker directly. An on-call engineer checks the channel each morning and responds to any flagged blocker within 30 minutes during business hours. We kept one weekly, real-time working session for discussion that genuinely needs everyone live, and removed status reporting from it entirely. In the first two weeks of the trial, on-time posting rose from 78 percent to 85.5 percent, and every India-based engineer on the team posted an update on every working day, for the first time in this team’s history.
We are completing the full trial before deciding whether to make this format permanent, and we will share what we learn when it ends. Going forward, we will evaluate any change to how this team works by whether it functions equally well at 9am and at 9pm, in every time zone we hire in. For a distributed team, that standard is not optional, and we intend to hold ourselves to it.
Jordan Ellis Engineering Manager Fernbridge Software
morning-experiment - Statement on the Unlogged Week (Days 31-37) June 24, 2026
This experiment did not quit. The public log went quiet for seven days after the Month 1 report because I was traveling for work and paused the routine along with the record, not because I gave up on either one.
log/days.csv received no new rows for days 31 through 37, and the weekly retro that normally posts on Sundays did not go up. Two people asked the same question in the repo’s discussion tab: whether this was the same shape as the 90-day attempt described in the README, the one that went quiet on day 11 and never started again. That is a fair thing to ask of a project whose whole premise is that a watching audience makes the routine more likely to hold. A missing week that looks like the start of a familiar pattern deserves a direct answer, not just a spreadsheet that quietly starts updating again as if nothing happened.
The missing week is logged now. Each of the seven rows is marked reconstructed in the notes column instead of being folded in with mornings that were recorded the same day, so the completion numbers in the Month 2 report stay honest about what was tracked in real time and what was rebuilt from memory afterward. The routine itself resumed on day 38, same 6:15 wake time, same four steps, phone still in the kitchen. Starting this week, any trip longer than two nights gets a one-line note in the log before I leave, so the next gap reads as planned rather than unexplained.
The Month 2 report on day 60 will include this week and the reconstruction exactly as they happened, not smoothed over to protect the percentages. If seven days of travel is enough to knock this protocol over, that is worth knowing plainly, and it is a better outcome than a clean-looking log that quietly stopped meaning what it says.
Me Author morning-experiment
Lattice Notify - Statement on the June 3 Notification Delivery Disruption June 4, 2026
Lattice Notify’s notification service runs on PostgreSQL, and after reviewing what happened on June 3, we are keeping it there. The service was slow to deliver notifications for a little over two hours because a database configuration limit was set too low for the traffic we saw that day, not because PostgreSQL was the wrong platform, and that limit has already been corrected.
From 2:17 PM to 4:37 PM UTC on June 3, roughly two hours and twenty minutes, in-app, email, and Slack notifications were delayed for every active workspace on the Lattice Notify platform. No notifications were lost or sent twice, but for that window, the people who depend on our customers’ products to notify them did not get notified when they should have. A surge of new workspace activity pushed the number of simultaneous operations against our notification database past the limit we had configured for it, and once that limit was hit, new notifications could not be accepted or sent until we intervened. A two-hour gap in notification delivery is a real problem for the teams who build on us and the people those teams serve. We are sorry for the disruption, and we are not treating it as minor.
We reduced the number of workers writing to the database to relieve pressure, which restored delivery at reduced speed within about an hour, then raised the configured operation limit to bring throughput back to normal and cleared the backlog of 14,200 queued notifications by 4:37 PM UTC. Since then, Jordan has been working on two fixes due June 10: raising that operation limit again, to twice our observed peak hourly rate, and adding hourly write-rate monitoring to our on-call dashboard. Ana is reviewing whether our launch capacity assumptions account for bursts like the one on June 3, with findings due June 17. Ana and Marcus are confirming, by June 24, whether the volume threshold we set for revisiting this database choice is still the right signal, or whether we need an additional one based on how concentrated the load gets within a given hour.
We chose PostgreSQL for this service because it let us build and run it with the team and the operational habits we already trust, and June 3 was a failure of capacity planning inside that choice, not a reason to abandon it. We will post an update once the monitoring and capacity work above is done. Until then, the standard we are holding ourselves to is the one we set when we made this decision: notification delivery that is reliable, on infrastructure we understand well enough to fix quickly when it breaks.
Ana Rivera Tech Lead Lattice Notify
Meridian - Statement on the Insights Dashboard Timeline September 26, 2026
Meridian is not going to ship the Insights analytics dashboard by the date we committed to this quarter. The dashboard moves to Q1 2027, and today we are releasing the underlying data as a CSV export so customers have access to their own data while we finish it.
Four customers were told directly, by name, that the Insights dashboard would ship this quarter, and sales built account plans around that date. A mandatory billing-system migration, required to meet regulatory and contract obligations, ran longer than planned and used the engineering capacity we had set aside for Insights. What we had built by the original date was missing saved-view persistence and scheduled-report delivery, the two capabilities those customers asked for by name. A dashboard without them would not have done what we told those customers it would do, and we chose not to ship it in that state.
We completed the billing migration because it could not wait. In its place, we are releasing a CSV export of the same event data the dashboard will eventually present, available now at no added cost through account settings. Customer success has contacted the four affected accounts directly this month, ahead of this statement. Engineering is targeting a March 13, 2027 release for the full dashboard, including saved views and scheduled reports. Design work begins in October, once the billing migration is stable in production.
We set a Q3 date before we understood what the billing migration would require of us, and that is on us, not on the customers who planned around it. We are changing how we commit to dates that depend on work still in progress elsewhere on the roadmap. Anyone with questions about the export or the March 2027 target can reach us at insights@meridian.io, and we will post an update here if that date changes.
Maya Chen Product Lead Meridian
Northlane Systems - Statement on New-Engineer Onboarding Practices
Section titled “Northlane Systems - Statement on New-Engineer Onboarding Practices”July 8, 2026
Northlane Systems holds new engineers to one standard, not one per team. Every engineer is excluded from on-call rotation for a minimum of thirty days, and that time exists to build real readiness, not to be spent solving access problems alone while waiting for someone to notice.
On July 3, we published an account of Priya Rao’s first two weeks on our Backend Services team: a named buddy in engineer Arjun Nair, full access within two days, a project scoped before her start date, and a production deploy in her name by the end of week two. That account was accurate, and we stand behind it. It also raised a fair question we owe a direct answer: is that the standard for every new engineer at Northlane, or was it the practice of one team that happened to write it down as ADR-0023 and had a buddy willing to absorb the cost? Until now, honestly, it has been the second. The guided-pairing protocol the Backend Services team follows has not been required of any other engineering team. Two engineers starting on the same day, on different teams, have not been guaranteed the same first two weeks.
We are closing that gap. Every engineering team is now required to run the guided-pairing protocol the Backend Services team documented in ADR-0023: a named buddy, access and tooling verified against a checklist inside the first two days, two structured walkthroughs in week one, and a real first change scoped before the new hire’s start date instead of discovered after it. That work is not free, and we are not going to describe it as though it were. It costs a buddy roughly 30 to 40 percent of their capacity in a new hire’s first week and 15 to 20 percent in the second. Sprint planning has treated that cost as time a generous engineer finds somewhere. Starting with each team’s next new hire, buddy capacity is a named line item in sprint planning, owned by the team lead and tracked by engineering leadership, not an assumption anyone is left to absorb quietly.
Here is what every new engineer at Northlane can now expect, regardless of team: a named buddy, a provisioned environment inside two days, and a real project waiting on their first morning rather than their third week. If that does not happen for a new hire on any team, we want to hear about it directly, and we will treat the gap as a failure of the standard, not an exception to it.
Dana Reyes Director of Engineering Northlane Systems
Sable Marchetti - Statement on the Record of the Alderton Platform Migration
Section titled “Sable Marchetti - Statement on the Record of the Alderton Platform Migration”June 30, 2026
For ten years, when I have told the story of my own career, I have told it as a story about my own judgment. That account is incomplete, and I am correcting it here: the decision that made the rest of it possible was Dana Forsythe’s, not mine, and any version of this story that leads with what I did is missing its first cause.
In March 2016, Dana nominated me to lead the Alderton platform migration. I told her I was not ready. She nominated me anyway and carried the professional exposure that decision created for the full length of the project. Over the following year she answered questions I had already asked her once, sat through stakeholder meetings without correcting me in the room, and declined to take the work back the one time I offered it to her outright, in a moment of real panic. The migration shipped in 2017. Dana now leads the data platforms group that grew directly out of that project, and in every retelling of my own career since, I have credited my own effort and left her decision out of the account. She has had no reliable way of knowing whether the six months she spent following my judgment instead of her own made any practical difference, or whether it was filed away as effort that did not amount to much.
That gap is what this statement closes. Effective today, the record includes what it should have included from the start: Dana Forsythe’s decision to nominate me before I was ready is the origin point of everything that followed, including work that has never carried her name. I am not correcting the record with language alone. In February 2026, I nominated Priya Osei to lead the Cassava data-pipeline rebuild on the same terms Dana used on me, before Priya felt ready for it, and I have stayed close without taking the hard calls back from her. She is currently four weeks ahead of her original schedule. The method is not mine. It is Dana’s, on loan, now in active use a second time.
Going forward, when I am asked how I became someone who could put Priya forward, Dana’s decision will be the first thing I name, not the last. This statement does not require a reply to stand. I am putting it on the record anyway, a decade late, because a debt that only exists privately is indistinguishable, from the outside, from a debt that was never owed.
Sable Marchetti Engineering Manager Ashgrove
Nora Kessler - Statement on Sunday Unavailability June 26, 2026
For fourteen weeks I have kept one full day away from work every week, and that is not changing. Sunday is off: no messages, no notifications, no task completion, no matter what is waiting when the day ends.
I know this past Sunday raised a real question for at least one client. A message sent that afternoon did not get a reply until Monday morning, and that is not an accident or a lapse. It is what a full day of rest, kept without exceptions, looks like from the outside: whatever arrives on Sunday waits until the day is over. The window in which my phone is physically out of reach has also been growing, from four hours overnight to ten, which means the gap has been getting longer, not shorter. If that has started to feel less predictable, that observation is accurate, and I am not going to minimize it.
Starting this week, that window moves earlier: it begins at Friday sundown instead of Saturday evening and holds through Sunday evening, so the transition is planned rather than abrupt. In practice, that moves the cutoff for anything time-sensitive from Saturday afternoon to Friday afternoon. I am also naming, by July 5, the one channel, whether that is the ticket tracker, the inbox, or the notifications feed, that I am most likely to check anyway out of habit rather than genuine need, so that channel carries an explicit rule instead of my judgment in the moment. None of this closes off real urgency. Anything that cannot wait can reach me by phone, and I will answer it.
This is not a temporary arrangement while I find something steadier. It is the arrangement: six days of work bounded by one day that stays off the table, including when the timing is inconvenient for someone waiting on a reply. Going forward, the rule is the same every week: nothing from me between Friday sundown and Sunday evening, and a response by Monday morning at the latest. I would rather state that plainly than have anyone piece it together from how long a message sat.
Nora Kessler Independent Consultant Kessler Consulting
Crestfield Group - Statement on Client Account Continuity After Howard Thayer’s Retirement July 6, 2026
Crestfield Group’s position is this: twenty-six years of institutional knowledge concentrated in one person, Howard Thayer, and that concentration was a real risk to the client accounts he supported directly, not just a fact about how long he worked here. His retirement on June 27 did not leave any of those accounts without a named, reachable successor, and we are treating the risk his departure exposed as a standing problem to fix, not a one-time transition to manage quietly.
Some of you have asked us directly, and more of you have asked the colleagues who manage your account, whether the service you depend on is now weaker than it was in May. We said plainly in our June 30 announcement that Howard carried judgment which had never been requested in writing: vendor escalation paths, four utility contacts that existed only in his personal records, and the decision sequence our team used when an automated alert did not tell the full story. That was accurate, and it is a reasonable thing to be concerned about. For twenty-six years, a meaningful part of how we served some of you ran through one person’s memory rather than through documentation that would have survived his absence. We are not going to describe that as anything other than what it was.
Between Howard’s notice in March and his last day, Dana Reyes and Marcus Okonkwo worked with him across structured sessions to record the escalation paths, the utility contacts, and the decision sequence referenced above into a runbook the team now owns jointly. Every system access and vendor credential Howard held transferred to three named successors by June 20, a week ahead of his last day, and each of those three is a direct point of contact today. Six colleagues Howard mentored separately compiled a record of how he worked through ambiguous situations, which will not replace his judgment but is more than existed in writing in May. The quarterly knowledge-capture practice we announced on June 30 is now standing department policy across every team, not only the one Howard led.
We are not going to tell you the transition is finished or that Howard’s judgment has been fully replaced, because it has not been, and claiming otherwise would be a worse mistake than the one we are already correcting. What we will commit to: every account has a named, reachable contact as of today, the first real test of the new runbook runs through an on-call rotation ending September 30, and if that test finds a gap, you will hear it from us before you find it yourselves. If you want to know who holds your account specifically, contact me directly.
Carolyn Marsh Operations Lead Crestfield Group
Northfield Commerce - Statement on Checkout Reliability June 29, 2026
For much of the past three years, checkout on Northfield Commerce has failed more customers than it should have, and we take responsibility for how long it took us to fix it. As of June 13, 2026, the checkout flow has been fully rebuilt end to end and is now handling all customer traffic.
During that period, customers using Northfield Commerce ran into dropped sessions mid-checkout, payments that failed on the first attempt and had to be retried, and a mobile checkout that in some cases would not render at all. Individually, our support team could resolve each case as it came in. Together, they meant carts were abandoned that should not have been, and customers lost time, and sometimes the item they were trying to buy. We heard about this directly from customers for at least three years before the work to fix it was finished. The length of that delay is on us, not on the customers who kept running into it.
Rather than patch a system we no longer fully understood, we built the new checkout as an independent service and spent fourteen months moving traffic to it gradually, cohort by cohort, so a new problem would surface in a small slice of traffic and could be caught before it reached most customers. Program lead Priya Vasquez and infrastructure lead Marcus Ferreira ran that migration from the first cohort to the final cutover; backend engineer Dev Okonkwo kept the old and new systems running side by side for the full fourteen months so that no customer saw a degraded checkout while the work was underway. We found two serious defects internally before a single customer did, in February and again in April of this year, and both times we chose to delay the launch rather than ship around the risk. Full cutover completed on June 13, 2026, and the new checkout held through its first weekend of peak demand without incident. Sam Wickfield’s team has since finished the regression work needed to retire the old system, which is now in a thirty-one-day read-only archive.
The old system will be fully decommissioned on July 14, 2026, once that archive window closes; until then it stays available as a fallback, out of caution rather than expectation. We are not claiming this fixes every problem a checkout can ever have. We are saying the chronic ones customers told us about for three years are gone, and we built this the slow way specifically so that would be true on day one instead of something we had to walk back later. If checkout gives you trouble now, that is the exception, not the pattern, and we want to hear about it.
Priya Vasquez Program Lead Northfield Commerce
Millbrook Software - Statement on Our Work Location Policy
Section titled “Millbrook Software - Statement on Our Work Location Policy”July 17, 2026
Millbrook Software’s work location policy is two mandatory office days each week, Tuesday and Thursday, and three fully flexible days for every other office-eligible employee. Employees hired into remote-eligible roles are not subject to the anchor-day requirement. That is the whole policy, published in full on July 14, and it has not changed.
Over the past few days, a Facilities email from the week of June 16 has been circulating publicly, including among some of our own remote-hired employees, describing an expectation of five-day-a-week office attendance. That email is real. It went out during a routine space-planning cycle that started before our work-location policy was finalized, and it reflected an assumption Facilities was operating on independent of the policy decision underway at the time. It does not describe our policy, and it never did. We understand why a document describing five-day attendance, surfacing days after we publicly announced a two-day policy, reads as evidence that the two-day framing is not the real plan. That is a fair question, and it deserves a direct answer rather than silence.
The June 16 email was superseded internally on July 6, when Facilities and our People team issued joint, corrected room-booking guidance aligned to the anchor-day policy, more than a week before we said anything publicly. We have published that timeline, and a direct answer to this specific question, in the FAQ accompanying the hybrid-anchor framework. Employees hired into remote-eligible roles remain fully excluded from the anchor-day requirement, exactly as documented at hire; nothing in this correction changes that. Anyone with a question about what actually applies to their role can reach our People team directly.
We published this policy, and the reasoning behind it, because people are owed more than the ambiguous “flexible” arrangement this organization operated under since offices reopened - one that meant something different in every manager’s hands. An old, superseded internal email resurfacing without its context is a reasonable thing to ask us about, and we would rather answer it plainly than let it sit unaddressed. The policy stands as announced: two anchor days, three flexible days, and no change to what we committed to the people we hired under remote-eligible terms.
Dana Okonkwo Chief People Officer Millbrook Software
Tidemark - Statement on Our Public Launch
Section titled “Tidemark - Statement on Our Public Launch”June 30, 2026
Tidemark turns customer feedback that is scattered across spreadsheets, chat threads, and ticket trackers into a single ranked, shareable roadmap. As of today, that product is available to the public. We are leading with that full description, not a shorter label, because a label is exactly what created confusion during early access, and we want our position on record before wider use begins.
Before today, twenty-two early-access teams used Tidemark, and what reached people outside that group came from what those teams called it in passing. Some called it a roadmap tool. Some called it a feedback tool. Neither is wrong exactly, and neither is the whole workflow: Tidemark reads feedback from wherever a team already keeps it, groups it into recurring themes, ranks those themes, and returns a roadmap the team did not have to assemble by hand. We understand why the shorthand traveled faster than the explanation. We also know that once a product is open to anyone, shorthand becomes the definition if we do not correct it ourselves.
Effective today, Tidemark is available to anyone, not only the waitlist. Existing waitlist members have same-day access; new sign-ups enter a rolling queue. Pricing is public and fixed, not set on a sales call: a free plan for individuals, twenty-nine dollars a month for teams of up to fifteen seats, and a custom plan for organizations that need SSO and audit logs. The eight help articles we staged for this launch, covering the core workflow, feedback import, ranking, and sharing, are live as of today, and they use the same description in this statement, not a shorter one.
Our commitment is to keep describing Tidemark by what it produces rather than by whichever category is easiest to file it under, even when the longer description is harder to repeat. On July 7, we will hold a structured retrospective with our early-access cohort to check the ranked output we shipped today against what they actually asked for, and we will publish what changes as a result. If this description stops being accurate, we will say so before anyone else does.
Marisol Veen Head of Product Tidemark
Marcus Delgado - Statement on the Closure of the Meridian Community Broadband Initiative December 18, 2025
I led the Meridian Community Broadband Initiative for eighteen months, and I am responsible for how it ended and for how the eleven people who volunteered their time were told about it. The initiative closed in March when its primary funder withdrew. That decision was made above the coalition and would not have changed no matter when it was disclosed. How the closure was handled afterward was mine to answer for, and I did not handle it well.
In February, the funder’s engagement had already begun to shift in ways that pointed toward where things were heading. I saw those signals and chose to keep the coalition, drawn from local library systems, a school district technology office, neighborhood associations, and regional internet providers, aligned around optimism rather than tell them plainly what I was seeing. When the funder withdrew in March, the closure arrived on a timeline the coalition had no chance to prepare for. I thanked the eleven volunteers who had given a year and a half of their time inadequately, in the middle of managing the closure itself, and this is the first time I am putting that plainly on the record. The infrastructure proposal this coalition built was sound. It did not reach the underserved communities it was designed to serve, and the partner organizations and residents who were counting on it are owed more than the silence they have gotten from me since March.
I am writing a complete account of the coalition’s work and the initiative’s closure, and I will deliver it directly to the eleven coalition members by the end of February. That document is theirs specifically. It will name the internal decision-making in full, including where I got it wrong, and it will not be published beyond the coalition. This statement is separate from that account and does not substitute for it. What I can put on the record now, for the coalition, the partner organizations, and anyone who followed this initiative’s work: the proposal was sound, the funder’s withdrawal in March ended it before it reached deployment, and the people who built it were not told plainly enough, soon enough, what was happening to the effort they had given so much time to.
Going forward, I will not manage how a difficult update looks before deciding whether the people it affects need to hear it sooner. That standard applies to this coalition and to any future work I lead. I do not expect this statement to change what the closure cost the eleven volunteers or the communities that will not get the infrastructure this proposal described. I am answerable for the fuller account still coming in February, and for doing this differently the next time an effort I am responsible for is at risk.
Marcus Delgado Independent Consultant Former Lead, Meridian Community Broadband Initiative