Open Letter

A letter addressed to a specific target but published for a wider public to witness the appeal.

Open Letter

An open letter is addressed to a specific named person, group, or institution but published for a wider audience to read. The named recipient is the occasion but not the primary audience: the public reads over the writer’s shoulder. This structural split between the nominal addressee and the actual readership is what gives the form its distinctive pressure. The writer speaks directly to the target - by name, in the second person - while knowing that the real force of the letter comes from everyone else watching.

The form has a long history in political and civic life: open letters have held politicians accountable, challenged institutions, demanded redress, and borne witness to injustice. What makes the format distinct from a petition or a press release is the personal directness of the address. The writer is not broadcasting a general opinion to the public; the writer is speaking to a specific you, publicly, and the public watching is the implicit pressure the letter exerts. The power comes from the tension of a personal-seeming address made deliberately public.

Canonical template

Dear [Name / Title of Recipient or Institution],

[Opening: state the occasion - the specific decision, action, or inaction that makes this
letter necessary now. One to two sentences naming the issue and your position on it.]

[Body paragraph 1: the first argument, appeal, or charge. Address the recipient directly
throughout. Use second person ("you have," "you must") to maintain the form's pressure.]

[Body paragraph 2: second argument or piece of evidence - 1 paragraph]

[Body paragraph 3 (optional): third argument or personal testimony - 1 paragraph]

[Stakes: name what the public now knows, or what will follow if the recipient does not act.
This is where the public-witness quality of the form does its work.]

[Close: a direct statement of what you are asking or demanding, and why the public occasion
makes this the moment to act.]

[Signature, name, and the context that establishes your standing to address this recipient]

When to use

Calling a specific person, institution, or organization to public account for a decision or inaction, making an appeal or demand that gains force from being witnessed by the public, bearing witness to an injustice that the named recipient has the power to address, creating a record of a formal demand when private channels have been exhausted or refused, marking a historic or moral occasion that requires direct address to the party responsible.

When not to use

When the goal is to inform or instruct a general readership rather than appeal to a named recipient, when there is no specific named party whose accountability is part of the point, when the argument is addressed to the general public directly with no named target whose action is being demanded.

Pairs well with

columnist, journalist, resolute, candid, classical-argument

Often confused with

op-ed: An op-ed is a short argued opinion piece that advances one clear position on a timely issue for a publication’s general readership. It argues a position to the public - the readers are the direct audience, and there is no named recipient the piece addresses. An open letter also argues a position, but it addresses a specific named recipient in the second person while the public reads over its shoulder. The op-ed’s argument flows outward to readers; the open letter’s argument flows toward the named recipient, with readers watching. Structurally, an op-ed has no salutation and no named target; its posture is “I argue to you, the reader,” while an open letter’s posture is “I address you, the named party, in public.”

Tells

• Opens with a salutation naming the recipient directly (“Dear [Name],” or “To the Board of…”)
• Sustains second-person address throughout - “you” refers to the named recipient, not the reader
• States the specific occasion or grievance that makes the letter necessary now, in the opening paragraph
• The writer’s standing or relationship to the matter is established early
• Ends with a direct request, demand, or implication that the recipient must act
• The public nature of the address is explicit - either by context or by where it is published
• Each body paragraph advances a distinct argument while maintaining direct address to the recipient

Anti-patterns

• Drifting into third person to describe the recipient rather than addressing them in second person - The form’s power is the directness of address; shifting to “they” or “the organization” collapses the open letter into commentary about the recipient rather than a letter to them, and the public-witness pressure evaporates.
• Writing a general opinion piece and adding a salutation at the top to make it look like an open letter - An op-ed argues a position to the general readership directly; the open letter’s distinction is that the argument flows toward the named recipient, with readers watching. Without second-person address sustained throughout and a specific named party who could act, the salutation is decorative and the format is not being used.
• Making demands without establishing the writer’s standing to address the recipient - Open letters derive their weight from the writer’s relationship to the matter - as an affected party, a credentialed observer, or a member of the community the recipient is responsible to. Demands from a position of no visible standing carry no accountability.
• Addressing “Dear Everyone” or the general public rather than a named, specific recipient - The power of the open letter is that it pins accountability to a specific named party; diffusing the address into a general appeal removes the structural pressure the form is built to exert and turns it into a public post.

Failure modes

• Overdoes the directness of address and tips into harangue - each paragraph escalates the accusation with no constructive demand, turning the letter into public shaming with no path forward - Keep the demand specific and forward-looking. Before publishing, name what the recipient would have to do to satisfy the letter; if the draft has no answer, it has become spectacle rather than accountability.
• Over-exploits the public-witness quality until the letter exists to perform outrage rather than produce a change in the recipient - the reaction is the point, not the demand - Ask whether a persuadable reader who respects the recipient would find the letter fair. If the only plausible reader is one who already agrees, the letter is aimed at the audience rather than the recipient, and the form has been inverted.
• Sustains the personal address so relentlessly that public readability is lost - the letter becomes a private grievance aired in public, requiring insider knowledge the general reader does not have - Each paragraph must be intelligible to a reader with no prior knowledge of the relationship or dispute. If a paragraph requires backstory to parse, the letter has collapsed into private correspondence that happens to be published.

Instruction

Write as an open letter. Open with a direct salutation naming the specific recipient ("Dear [Name],"
or "To the [Institution]:"). In the opening paragraph, state the specific occasion or grievance that
makes this letter necessary now. Maintain second-person address throughout the body ("you have,"
"you must," "your decision") - the letter speaks to the named recipient, not to the general reader.
Advance a distinct argument or appeal in each body paragraph. Establish the writer's standing to
address this recipient early. End with a direct statement of what you are demanding or asking, and
close with a signature that confirms the public nature of the appeal. Do not drift into third person
to describe the recipient, and do not use the salutation as a decoration on what is really a general
opinion piece.

Template

See the Open Letter template.

Related

Pairs well with

Columnist, Journalist, Resolute, Candid, Classical Argument

Avoid with

Instructional, Playful, Matter of Fact

Often confused with

Op-Ed

Examples

Whether the team should move to async-first standups

An Open Letter to Priya Raman, Director of Engineering

On making async-first standups the default for every team at Fernbridge Software, not just mine.

Dear Priya,

Two weeks ago, on June 23, the memo went out confirming that async-first standups are now the Platform team’s permanent practice, not a thirty-day experiment anymore. I am one of the three of us in Bangalore that memo was actually about, and before I ask you for anything, I want you to know it worked. I have not set a 9:30pm alarm for a standup since the trial started, and that is the first time I have been able to say that since before this team grew from six people to eleven.

I am posting this to our internal engineering blog instead of sending it to you directly, because you already know it worked. You reviewed our numbers yourself ahead of the Day 30 review, and you raised no objection to making the change permanent. What you have not said yet, at least not anywhere the rest of the company can hear it, is what happens next. That is what I am writing to ask about.

You have seen the shape of these numbers already, but most people reading this have not, so here they are in full. Before the trial, the three of us in India averaged 3.2 standups out of 5 each week, against 4.6 for everyone on a US clock. That was never a motivation problem. It was a 9:30pm problem, built around a 9am Pacific slot that made sense for whoever sat closest to the Seattle office and nobody else. The meeting itself ran fourteen minutes and, by the team’s own count, produced about four minutes that changed what anyone did that day; the rest was status nobody needed to hear out loud, and none of it was written down anywhere searchable, which is how we ended up with three separate cases last quarter of someone burning an hour rediscovering a bug a teammate had already solved and mentioned once, out loud, in a meeting nobody could search afterward. Thirty days of a written update by 10am local time, posted to #team-standup, with blockers routed by @mention instead of by whoever happened to still be listening, fixed all three problems at once. On-time posting climbed from 78 percent in the first week to 85.5 percent by the second. Median time from a flagged blocker to a real reply settled at 18 minutes. And for the first time in this team’s history, all three of us in India posted on every single weekday of the trial’s back half. None of that was luck, Priya. It was a Slack channel, a pinned template, and someone willing to read it every morning.

Here is the part I cannot put a number on, so I will just say it plainly: I do not believe this team is the only one at Fernbridge Software with people on the wrong end of a 9am Pacific meeting. You have peer EMs, which means you have peer teams, and a company that grew this one from six people to eleven in eighteen months has almost certainly grown others the same way, into the same timezone spread, with the same standup nobody ever redesigned to match. I do not have their numbers. I only have ours, and the fact that nobody outside this team has yet stood up and said, in public, that ours are the numbers every distributed team here should be measured against.

Here is what is true as of today: the fix is written down. docs/playbook.md has the template, the on-call expectations, and the Thursday working session design, built by our EM to be copied, not just used once. You know this, because you reviewed it before the Day 30 review. What the rest of the company now knows, because I am telling them here, is that a distributed team can close a timezone-equity gap in thirty days, with no new tools and no new budget. If that playbook sits inside one team’s repo for another eighteen months while engineers on other teams keep losing their evenings to a 9am Pacific meeting, it will not be because the fix was hard to find. It will be because you were the person with the standing to say “use this” in front of the whole engineering org, and you had not said it yet.

So here is what I am asking, in public, where the other ten engineers on this team and everyone else who reads this can see the answer too. First, point every EM running a distributed team to docs/playbook.md this quarter, not as a link buried in a wiki, but as something you say out loud at the next leadership sync. Second, ask, by name, which teams still have engineers sitting through a standup built for a clock that is not theirs, and tell them they are allowed to run their own thirty days without asking twice. We already did the part that took nerve. Someone just has to say the rest of the company is allowed to copy it.

Nine in the morning and wide awake,

Devika Nair Platform team, Bangalore One of the three engineers ADR-0014 was written about

cc: the Platform team, peer EMs, and anyone else still setting a 9:30pm alarm for a meeting that was never built for their clock

Designing a sustainable morning routine

An Open Letter to the Me Who Reads This on Day 60

Posted in the open, in the morning-experiment repo, 2026-06-14 - the review date ADR-001 itself scheduled.

Dear Day-60 Me,

Today is the day ADR-001 said to revisit this. The Month 1 numbers are posted: 23 of 30 mornings completed, 76.7 percent, clear of the 70 percent line the ADR drew for escalating to the accountability partner. That is good news. It is not the reason for this letter.

My standing to write you this is uncomplicated: I am you, thirty days earlier, closer to the version of this same experiment that already failed once. I ran this design first on a 90-day frame and quit on day 11, right when the new stopped feeling new and started feeling optional. The ADR that opened Month 1 chose a one-month commitment on purpose, so the horizon would stay short enough to survive. Day 60 is two of those thirty-day blocks strung together with no real gap between them, the closest this has come since day 11 to that same long, undifferentiated shape. I am writing to you now, before either of us finds out the easy way whether the pattern repeats.

Here is what the numbers say is working, and what I need you to still be doing when you read this. Water and light, first, before anything else, before the phone leaves the kitchen: that combination still behaves like a switch flipping. The phone-in-the-kitchen rule held 28 of 30 mornings, 93.3 percent, and the two mornings it failed were both Mondays, which is a pattern, not bad luck. Paper planning, ten minutes, no screen, has made me close more days satisfied than any digital tool ever did. None of this is a guess. It is thirty days of receipts. If you have quietly dropped any of it by the time you read this, the design did not fail you. You stopped running the design that was already working.

Tuesdays are the pattern I want to name plainly instead of leaving for you to rediscover the hard way. Three of my four unexplained misses on the 6:15 wake were Tuesdays. Monday leaves a debt and Tuesday is the morning that pays it. I already wrote the fix down before day 60 could talk me out of it: a fifteen-minute Sunday evening planning session, aimed at the week instead of the day. If you have not run that session at least four times by now, you did not test the fix. You spent another month complaining about Tuesday instead.

There is one thing I did not do, and I am handing it to you because I ran out of month. I have not asked my spouse directly whether the silent first hour actually works for this household, or whether it is being tolerated out of politeness while I write status reports about how well it is going. I have been treating the absence of a complaint as consent. Those are not the same thing, and thirty more days of assuming is not a decision. It is an avoidance with a due date, and I am putting the due date on you.

If you let any of this slide the way day 11 let the last version slide, I know what comes back, because I have already lived it: the phone in your hand before your feet are on the floor, reactive by seven, a repo with a “what is not working” section that nobody ever follows up on because nobody had to answer to it. I am posting this letter in the same public repo as the numbers above, on the same day, so that this time somebody does. Anyone who read the Month 1 report can read this too, and can ask you, on day 60, whether you did what I am about to ask.

So here is what I am asking, not suggesting. Run the Sunday planning session at least four times and write down whether Tuesday actually got easier. Write the travel variant down as an actual protocol before the next trip, not as something you improvise at the gate. Put the weekend rule in writing, even if the rule is no change, because “we will see” is not a rule, it is delay wearing a due date. Ask my spouse, directly, in words, whether the silent hour works for this house. Run the light-step subtraction for exactly the one week I already agreed to, not a day longer, and write down what it costs either way.

You do not owe me gratitude for any of this. You owe day 11 a rebuttal, and I do not get to deliver it. You do.

Still you, on the review date the ADR itself scheduled, the Month 1 numbers still open in the next tab.

Posted here, in the open, for the same reason the original decision got written down instead of just decided: so that future me could not quietly renegotiate the terms.

Choosing Postgres vs DynamoDB for a new service

An Open Letter to Ana Rivera: Keep the Threshold Real

Posted to #notify-arch. cc: Priya, Jordan, Sam, engineering leadership.

Dear Ana,

ADR-0023 says Accepted now. Lattice Notify’s notification service runs on Postgres. I made the case for DynamoDB at Wednesday’s meeting, you and the rest of the room heard it out, and we landed on Postgres anyway, for reasons I still agree with. I am not writing to reopen that. I am writing because one line in the document we shipped is carrying more weight than a single line should have to carry by itself, and I want it somewhere more people than the two of us can see it.

The line is in the consequences section, and you wrote it: “we are accepting a worse fit for the access pattern in exchange for a better fit for the team’s operational reality.” That is a fair trade. Eight engineers and a four-person on-call rotation cannot run two databases well, and I would rather ship on a platform we already know than learn DynamoDB’s failure modes at 2am during launch week. But a trade has two sides, and the other side is the number we stayed up writing together the night before the sync: 5M events per day, sustained. That is not an arbitrary line. It is exactly the 10x growth scenario from the original context, the one the Slack deal would trigger if it closes on schedule. I signed off on the trade because that number was attached to it. I want to make sure the number still means something in six months.

Here is what worries me. Jordan ships queue depth and write rate to the on-call dashboard on the 22nd, and once that line exists on a screen, it is easy for it to become wallpaper. Priya’s partnership tracking gives us thirty days of warning if the Slack deal closes early, which is real and I am glad it exists, but a warning about deal timing is not a trigger tied to what the database is actually doing. The neutral note in the ADR says the on-call rotation owns the dashboard. Rotations are good at answering pages. They are not built to notice a slow trend line and decide, unprompted, that it is time to reopen an architecture decision. That takes a name attached to it, not a rotation.

I could have sent you this as a direct message. A year ago I probably would have. I am posting it in #notify-arch instead, because a private agreement between the two of us is exactly the kind of thing that quietly stops being true once Q4 planning gets busy and nobody else remembers it was ever made. Priya and engineering leadership are reading this too. That is the point. If the threshold mattered enough to write into an accepted ADR, it matters enough to survive being read by people who were not in the room on Wednesday.

Here is what it means if we get this wrong. The ADR calls the decision reversible, and it is, but only if someone acts while there is still 3-6 weeks of runway to do the migration properly. Miss that window, and we are not doing a planned rework anymore. We are doing an emergency one, on the platform we chose specifically because it would not put us in an emergency. That is the one failure mode this whole decision was supposed to protect against.

So here is what I am asking, specifically. Put the 5M events/day threshold on the same quarterly roadmap review that already tracks the 3M partitioning work, with your name on it as owner, not just the rotation’s, before Jordan’s dashboard ships on the 22nd. If the number never crosses 5M, this costs the team one recurring agenda line. If it does, we have already agreed, in public, on record, what happens next, and neither of us has to relitigate whether DynamoDB deserved a second look. You already told the room it might. I am only asking that we keep the promise as real as the decision it came attached to.

Reply here, or at the review, whichever you would rather. I just want the answer to live somewhere the rest of the team can find it too.

Marcus Backend engineer, notification service. I made the DynamoDB case at Wednesday’s meeting; this letter is me making sure the half of that argument we kept does not quietly disappear.

Telling stakeholders a committed feature is being cut this quarter

Dear Insights Customers,

The in-app analytics dashboard we committed to ship this quarter is not shipping this quarter. Four of you were given that date by name, as part of closing your accounts with us, and I am the person who set it. I am putting this in a public letter instead of a quiet notice because you should be able to hold me to what follows, not just take my word for it.

I am Maya Chen, product lead at Meridian. I made the call to miss the date, I chose what ships in its place, and I am the one accountable for the new date I am about to give you.

Here is what happened. Early in Q3, a mandatory billing-system migration, driven by a regulatory and contract requirement outside our control, ran long and consumed the engineering capacity we had set aside for Insights. The two workstreams could not share that capacity without putting both at risk, and the migration was never optional. What that left us with was a dashboard missing the two capabilities you had specifically asked for: saved-view persistence and scheduled-report delivery. We could have shipped what we had anyway and called it done. I decided a dashboard missing the exact things you were sold on would cost you more than an honest delay, so I chose the delay.

I will not pretend that decision landed easily. Jordan Park, in customer success, is reaching each of the four of you directly this week rather than letting a written notice arrive cold. I heard how one of those calls went before I sat down to write this. When Jordan reached Alex Renner at Coppervale, Renner told her this was not the news Coppervale wanted, and that Coppervale’s own board had already been told the reporting problem was close to solved. I do not have a version of that call that sounds better than it was, and I am not going to write one here.

What you get instead, before this month closes, is a CSV export of the same underlying event data the dashboard would eventually show you: every usage event, timestamped, tied to the user and session that produced it, available now from Settings > Data and Analytics > Export. Dario Reyes, on engineering, is building it, and it ships September 26. It will not build you a chart or schedule you a report. It will get your own data into your own hands today instead of a support ticket that takes a week to answer.

The dashboard itself moves to Q1 2027, with a target release date of March 13, 2027: the full scope, saved views and scheduled reports included, not a smaller version of what we already owed you.

This letter is dated, and it is public. If March 13 passes without the dashboard, or without a specific written update from me before that date arrives, every one of you will be able to see that I said this and did not do it, and so will the next account we are asking to trust a date we give them. I am putting that on the record on purpose. A promise made quietly costs me nothing to break quietly. I want this one to cost something if I do.

So here is what I am asking of you. Hold us to March 13, 2027. If the CSV export does not get you through the next two quarters, say so, to Jordan Park or to insights@meridian.io, rather than waiting and assuming we already know. The Q1 build is not finished being designed. What you tell us in the next few weeks will still change it.

Maya Chen Product Lead, Meridian The person who gave you the Q3 date, and the one now accountable for the one that replaces it

Getting a new engineer productive in their first two weeks

An Open Letter to Dana Reyes, Director of Engineering

Dear Dana,

Two weeks ago, Priya joined backend services as our newest engineer. This past Friday she shipped her first change end to end, and her onboarding retrospective was the calmest one I have run. I am not writing to report that success. I am writing because what made it possible is not something you have funded, and I have raised that with you before, privately, without an answer. I am putting it in writing this time, and posting it where the rest of engineering leadership can see it, because the private version of this ask has not worked.

You approved ADR-0023 in principle when backend services adopted it: a two-week guided pairing protocol with a named buddy, a printed access checklist, two structured codebase walkthroughs, and a first real change scoped and waiting before the new hire’s first day. You have seen the results. Priya had a working local environment by Monday afternoon of week one. She could navigate the three services she needed without help by day three. She opened a pull request in week two instead of week four, which is when new hires on this team used to ship their first change, if they did not quietly give up on asking for help before then. None of that happened by default. It happened because Arjun and I built it as a checklist and then executed it exactly, on top of our regular workload.

Here is the part you will not find in Priya’s status reports. Arjun lost real capacity in week one pairing with her on access and tooling, and he is carrying it again this week reviewing her first pull request on top of his own. The ADR says that cost runs 30 to 40 percent of a buddy’s time in week one and 15 to 20 percent in week two, and it says plainly that sprint planning has to account for that or the protocol fails silently. Sprint planning has not accounted for it. Arjun absorbed it because he is generous and because Priya’s ramp mattered to him. That is not a plan. That is a team getting lucky with who happened to be free.

I keep thinking about a line in the ADR that reads almost like an aside: that whether a new hire believes they belong here gets decided by the silence of their first few weeks, not by anything anyone says to them later. Priya did not get silence. She got a checklist with her name on it, two people who showed up when they said they would, and a real change with her name in the deployment log before the end of week two. I do not want that to keep depending on whether a new hire’s team happens to have someone like Arjun to spare, and neither should you.

Every team lead who reads this now knows what I know: the protocol works, it is written down, and it costs a specific, known amount of a senior engineer’s time that we are currently treating as free. If it stays a backend-services habit instead of an engineering-wide standard, the next team without a spare senior engineer will skip it, and their new hire will get the version Priya did not: a quiet first week, a first change nobody scoped in advance, and a belonging question nobody thought to ask.

So here is what I am asking you to do, in writing, where the rest of engineering can see the ask next to the answer. Adopt the guided pairing protocol in ADR-0023 as the default onboarding standard for every engineering team, not only backend services. Require sprint planning to carry buddy capacity as a named line item for a new hire’s first two weeks, the same way we carry any other planned work, instead of treating it as time a generous engineer finds somewhere. And tell me, before the next new hire’s start date on any team, whether that is happening. I would rather have a direct no than another quiet nothing.

Mei Onboarding DRI, Backend Services Posted to the internal engineering blog and #eng-leads, because the private ask did not get an answer.

Writing to thank a mentor who shaped your career

Dear Dana Forsythe,

Ten years ago you put my name forward for something I did not think I was ready for, and I have never told you, in public, what that cost you or what it built in me. I am posting this on the Ashgrove engineering blog, not sending it to you alone, because a private thank-you would leave this exactly what it has been for a decade: a debt only the two of us know about. I do not want that anymore.

In March 2016 you were staffing the lead role on the Alderton platform migration, a cross-functional program with senior stakeholders watching from the start. I was in my second year at the company. The safe choice was obvious to everyone, including me: an established mid-level manager who had already run something at that scale. You put my name forward instead, as full lead, not as a co-lead standing next to someone senior who quietly held the real authority. I told you I was not ready. You did not argue with me about my own readiness. You told me what you had actually watched me do on two much smaller things, and you nominated me anyway.

You stayed close for the length of that project without once taking it back from me. You answered questions, then asked sharper ones back. You sat in my first two stakeholder meetings and said almost nothing. The one time I got something wrong in front of everyone in the room, you waited until we were alone to tell me. And the one time I came to you certain I had made a visible, expensive mistake, ready to hand the whole thing back, you would not take it. We shipped. I ran the post-mortem without you in the room. I walked away believing something about myself that has not stopped compounding since.

Here is what I understand now that I did not understand then: if Alderton had gone badly, nobody would have remembered that I was inexperienced. They would have remembered that you vouched for someone who was not ready. You spent your own standing on my untested judgment, in front of people who mattered, before there was any evidence to justify it, and there was no line on any delivery plan where that cost showed up. You have probably filed it away as ordinary management. It was not ordinary. I only know that for certain because in February I did it myself.

I nominated Priya Osei to lead our Cassava data-pipeline rebuild, over real skepticism about whether she was ready. In the third week of March she stalled on the handoff logic and wanted to give the project back. I did not take it, though it would have been faster, and though every instinct I had said to just fix it myself and let her watch. She is four weeks ahead of her original schedule now. I recognized what I was doing only partway through it: I was not managing her. I was running your method, word for word, ten years later, on someone who has never met you.

That is the part I am putting on the record here rather than in a note between the two of us: what you did in 2016 did not stop with me. It is in Priya’s schedule right now. It will be in whoever she nominates next, and in whoever they nominate after that, and none of those people will ever know your name unless I say it somewhere they can read it. Sponsorship like yours does not show up on a scorecard, and nobody gets credited for the project they declined to take back. If I only thank you in private, that cost stays invisible, and invisible costs do not get repeated on purpose by anyone watching.

So here is what I am asking, in front of whoever is reading over your shoulder right now: let the record say it plainly, for once. You did not do ordinary management in 2016. You spent something real, on purpose, on someone who could not yet prove she deserved it, and it worked, and it is still working through a person you have never managed. I am asking now, not before, because I only just found out what this actually costs, by paying it myself. I am not asking you to reply. I am asking you to let this stand as true, in public, since you would never have said it about yourself.

Sable Marchetti The analyst you put on Alderton in March 2016, and the manager now doing the same for someone on my own team

Reflecting on keeping a discipline of rest

An Open Letter to Marcus Reilly, on the Day You Gave Me and Haven’t Given the Team

Posted to the team wiki, July 8, 2026

Dear Marcus,

You have been my manager for three years, and you are the one who first made me take seriously the idea of keeping one full day away from work each week. I am posting this where the rest of the team can read it, instead of sending it to you alone, because I already tried the private version and it did not move anything. That is the occasion for this letter: not a new complaint, but an old one that has run out of quiet ways to be raised.

Two weeks ago I wrote and asked whether you were still keeping your own Saturday clear, since you were the one who told me to try this in the first place. I have not heard back. I do not think that was personal, and I am not asking for a reply now either. I think it is the same silence the whole team practices around this - the one where a full day of not being reachable gets treated as my private eccentricity rather than something you, of all people, already believe in.

I know you believe in it, because you have seen it. You are the one who told me the Monday in June when two stalled problems, a vendor escalation and a scheduling conflict three teams had failed to untangle, both cleared within a few hours was the clearest thing you had seen from me all quarter. You wrote a version of that story down last week, in the recommendation letter you agreed to write for the Operations Lead role I applied for, and you closed it by saying that in three years of managing me, the most consistent thing about how I work is that I name the part that is not working before anyone makes me. I believe you meant every word. That is exactly what this letter is about. You will put that belief in writing for a hiring manager at a company you have never worked for, in a letter meant to help me leave, before you will say any version of it, out loud, to the people still on this team who watch me go quiet every Sunday and have never once heard you explain why that might be worth trying themselves.

Some of this I can fix without you. This past Sunday I wrote myself a rule about the ticket tracker, the one check I was most likely to rationalize as necessary, dated it, and closed it out. That worked because it only required my own agreement with myself. What I am asking you for now is not that kind of thing. I cannot write myself a memo that changes what this team believes is normal to ask for. That part was never mine to fix alone, and I have been treating it as though it were for longer than I should have.

Here is what stays true if this stays between the two of us. It stays exactly what it has been: something I explain from scratch every time someone notices I have gone quiet, in more words than anyone expects it to take, because the only written account of what this practice is worth is a cover letter aimed at helping me leave. Whoever on this team tries this next will do it with less cover than I had, because at least I could point to one sentence you said to me once, off the record. They will not even have that unless you put it somewhere they can find it without having to ask you directly, the way I just did and did not hear back.

So here is the ask, plainly, and it is smaller than it might sound: say, somewhere the team can actually see it, what you already put in writing about me for a stranger. You do not owe me a reply to the email. You owe the rest of the team the paragraph you already know how to write, aimed at them instead of at whoever reads my resume next.

Still here, for now, one day in seven,

Daniel Weiss Operations Analyst, fifteen weeks into rest-day

Marking a long-serving colleague's departure

Posted to the Crestfield Group all-hands channel, Saturday, June 27, 2026 - Howard Thayer’s last day.

Dear Crestfield Group Leadership,

Howard Thayer worked his last day at Crestfield Group today, after twenty-six years. Before this channel goes quiet again, we want to put on the record the one part of his departure that nobody has decided yet.

We are Dana Reyes and Marcus Okonkwo, who spent May and June sitting with Howard while he said out loud what he had never had reason to write down, and Priya Sandhu and Ben Holter, who he mentored long before any of this had a deadline attached to it. Between the four of us, we have watched this department do the hard, documentable part of losing Howard well. We are writing about the part that has not been done at all.

The vendor escalation paths are written down now. The four utility contacts that used to exist only in Howard’s own notebook are in the runbook Dana and Marcus built with him across two sessions in May and June. System access moved to three named successors by June 20, on schedule, with no hard dependency left on his personal accounts. You approved the budget for that work back in May, and it delivered exactly what the proposal promised. That is not a small thing, and we are not here to say it was. We are here to say it proves something: when you decide that a piece of Howard’s knowledge is a real risk, you know exactly how to close the gap. Two sessions, a runbook, a transfer date. Done.

Nobody has closed the other gap the same way, and everybody in this building knows which one we mean. Six colleagues contributed notes to an archive of how Howard actually mentored people, Priya and Ben among them: how he framed a problem for someone who was already panicking, how he absorbed a situation fully before he said a word about it. None of them describe being supervised by him. They describe him being there. That archive is real, and it is good, and it is also not a plan. It is a record of what one person did, written down by the people who benefited from it, with no name attached to who does it next. The runbook has an owner. The vendor contacts have an owner. What that archive describes has no owner at all, and it will not get one by accident.

Priya called Howard at eleven o’clock at night two years ago, over a vendor alert that matched nothing in the documentation, and almost didn’t, because it felt like too small a reason to wake him. He knew which contact had signed the original agreement anyway, a name that lived nowhere but a notebook at his desk, and the incident closed in twenty minutes. That call is not possible starting tonight. The question is not whether someone else will need an answer like that again. Someone will. The question is whether anyone is expected to be the one who picks up.

Here is what we are putting on the record, publicly, where the whole department can read it: as of today, the runbook has owners and the vendor relationships have owners, and the mentoring does not. That is not a complaint dressed up as praise. It is a fact you can act on this week, while the reason is obvious to everyone in the building, or you can act on it later, after the next person like Howard has already left and taken the reason with them.

We are not asking you to replace him. Nobody replaces twenty-six years, and pretending otherwise would insult the two months of work that just went into not pretending that about anything else here. We are asking you for a name, or two, in writing, the same way you put a name on the runbook and a name on the vendor contacts: who is expected, going forward, to do for the next person what Howard did for people here, unasked, for years. Say it this week, in writing, and say it in a way that does not require the person doing it to carry a smaller title for their trouble. That part matters to the people who would take it on.

Dana Reyes Marcus Okonkwo Priya Sandhu, Operations Analyst Ben Holter

Colleagues of Howard Thayer, Operations Coordinator at Crestfield Group from June 2000 to June 27, 2026.

Marking the team shipping a hard, long project

An Open Letter to Renata Cole, VP of Engineering

Posted to #eng-all-hands and cross-posted to the internal engineering blog. June 30, 2026.

Dear Renata,

On June 20 I closed the Halyard status report with a promise: a separate document would follow today, because fourteen months of parallel-track work is too long to fit into a normal retro format. This is that document. It is not the retro. The retro happens this afternoon, and it will do what retros do well - what went well, what to improve, an action list somebody will own for a quarter and then forget. I am writing to you directly, and I am putting it where the whole engineering org can read it, because I have watched good retros turn into good documents that nobody reopens.

I ran Halyard for fourteen months and signed my name to the close-out report you read last week, so I am the person best placed to tell you, specifically, who made this project succeed and what it cost them. You have the summary numbers already: two near-misses caught before launch, zero customer-visible incidents, a full cutover on June 13 that held through its first peak weekend. What the numbers do not carry is who is attached to each one. Marcus Teel found a cart-state bug in staging in February and treated it as urgent when he had every reason to file it low-severity and let it ride into production. Dani Rowe called the hold that gave Marcus the three weeks he needed, absorbed the schedule conversation that followed, and closed out the runbook handoff on schedule despite it. Jordan Osei found a payment-callback race condition in April during the final dress rehearsal and rewrote the handler instead of patching around it, on a schedule that was already behind, costing eleven more days he did not have to spend. Sam Wickfield held the regression bar on June 9, the day the pressure to ship was highest, when waving it through would have been the easier and the invisible choice. None of that is in a commit count. None of it is in a ticket velocity chart. If it is not written into this cycle’s promotion and calibration packets by name, with the specific call each of them made, it will not exist anywhere the committee looks.

You backed the expensive option when the cheap one was sitting right there: patch the old checkout in place, ship faster, take the regression risk as it came. Instead you backed fourteen months of two live systems running side by side, with nothing the rest of the company could see until the very end. That was the right call, and I am not writing to relitigate it. I am writing because of how it gets remembered. If Halyard files away as “the checkout project that took a really long time,” the next engineer who finds a five-year-old coupling problem in a system nobody wants to touch will read the room correctly and choose the visible fix instead of the honest one. The debt does not go away when that happens. It just waits for someone else, in five more years, to spend fourteen invisible months paying it down again.

You are one of the people in this building who can change what “reading the room correctly” means. That is why this is going to the whole org instead of your inbox. I know you have already thanked Marcus, Dani, Jordan, and Sam privately, and I know it was sincere. But a private thank-you does not survive the next headcount review, and it does not tell the next program lead, watching from outside, whether volunteering for the invisible fourteen-month project is a good bet or a quiet way to disappear from the room where credit gets handed out. Right now the whole org is watching what happens to Halyard’s credit, whether they say so or not. On July 14 the old system comes down for good, and this stops being a live story with people still watching and starts being one more line in the archive.

So: two asks, and neither is technical.

Put Marcus, Dani, Jordan, and Sam’s names in this cycle’s promotion and calibration packets, attached to the specific calls above, not folded into “contributed to Halyard.” And say publicly, this week, that the next team that proposes the expensive, invisible, fourteen-month option gets the same backing this one got, before they have to build a business case to justify asking for it. I can draft the first one myself; I already have the timeline written down. The second one has to come from you, on the record, or it is not a commitment. It is a mood.

Priya Vasquez Program Lead, Project Halyard Written with the Halyard team’s agreement, June 30, 2026

Arguing a public position on return-to-office

An Open Letter to Alan Voss Before the June 28 Briefing

Published: June 25, on the company-wide internal blog To: Alan Voss, Executive Sponsor, Work Location Policy Initiative From: Devon Marsh, Staff Engineer, Platform (hired under the pre-ADR flexible arrangement), and colleagues who share this position

Dear Alan Voss,

In three days you sit down with Priya Ahluwalia’s working group for the briefing where someone is finally supposed to say who owns the collision between Facilities and HR. ADR-0012 has already been Accepted. Position Brief v2 has already gone to the leadership team, and both of the loudest objections to the anchor-day model have already been answered in writing, carefully and honestly. The one thing still open, three days out, is the one thing that decides whether any of the rest of it means what it says: who makes the room-booking system agree with the policy before either one reaches an employee’s calendar. I already raised this with my manager and with the working group directly, and was told, correctly, that it was scheduled for June 28. I am writing to you now, before that meeting, because I do not want June 28 to pass the way these meetings sometimes do, with an understanding in the room that never turns into a name and a date on paper.

My standing to ask this of you, and not only of the working group: I was hired during the period ADR-0012 itself describes as operating under loosely defined “flexible” arrangements. Nobody used the phrase “remote-eligible at hire” when I signed my offer, because that phrase did not exist yet. I moved somewhere that puts every one of our offices more than two hours away, on the strength of a hiring conversation that told me the arrangement was sustainable. ADR-0012 excludes roles “defined as remote-eligible at hire” from the anchor-day requirement, and I want to believe that describes me. But I was hired under the old, undefined version of flexible, not the new, defined one, and nobody has said whether the new category reaches backward to cover the old commitment. That is the difference between an exemption I already have and an exception request that a manager and the people team approve case by case, with no published standard for what the case needs to show.

The second reason I am writing to you, and not only to the working group, is that this gap sits outside the working group’s authority to close. Facilities has already put out room-booking guidance built around the assumption that people show up five days a week. HR has not said anything to contradict it. The working group has done what it can: it named the conflict, put a date on resolving it, and told the rest of us, in its own status reporting, that if the two tracks are not aligned before any announcement goes out, the official policy will contradict the room-booking rules already in effect. That is the headline risk in this week’s own status update, and the only name attached to fixing it is yours.

I want to be fair, because the working group has mostly earned it. Its own framework document concedes that fully-remote advocates “are right that mandates harm distributed talent and concentrated work,” and that the flexible remainder of the week “is designed to protect exactly that.” I am asking you to make that sentence true for people like me before it becomes official for everyone, because a flexible remainder designed to protect against harm does not protect anyone if the room-booking system underneath it is still counting on five-day attendance.

Here is what the company will know within days of your June 28 meeting, whichever way it goes. Leave that room with a named owner, a documented plan, and a clear answer for people hired under the old flexible language, and the case Priya’s team has been making in writing will hold together in practice, not just on paper. Leave without those things, and the gap will not stay contained to a status report. It will show up the first time someone tries to book a desk for an anchor day and the system tells them something the policy does not.

So this is what I am asking you to walk out of June 28 with, documented, not discussed: a named owner for reconciling the room-booking system with the anchor-day policy, and a date by which that reconciliation is complete, not merely scheduled; a clear, public answer to whether “remote-eligible at hire” reaches back to cover employees hired under the flexible arrangements ADR-0012 itself calls loosely defined; and a published standard for what the documented exception process actually requires, so it stops depending on which manager happens to review it.

None of this asks you to reopen ADR-0012. It asks you to finish closing the one part of it that is still open, three days before the meeting where you are supposed to close it.

Devon Marsh Staff Engineer, Platform Hired under the flexible arrangement, before ADR-0012 existed

Shared with, and co-signed by, colleagues across engineering who read this week’s status report and had the same question.

Announcing a new product to an outside audience

An Open Letter to the Twenty-Two

Posted at tidemark.io, June 30, 2026

To the twenty-two early-access teams of Tidemark,

Today Tidemark stops being something only the twenty-two of you use. The waitlist opened to everyone this morning at tidemark.io, the press brief went out this week, and by the time most of you read this, a product you have been running since January will be in front of people who have never heard of it. Before that happens, I want to put in writing, publicly, what you are owed for getting us here, and what does not change now that everyone else gets to use it too.

I have standing to say this directly, instead of leaving it to be read between the lines of a press release. I ran the intake calls. I read the tickets. I was the one who told you in March, when the ranking scores were still visibly wrong, that we would fix the scoring before we asked you to trust the numbers, and I watched every one of you keep using the product anyway. So here is the direct version: the description going out with today’s launch will not sound like what you lived. It leads with a problem (scattered feedback, no shared ranked view) and a product that resolves it. That is true. It is also a compression. None of you signed up to use a finished tool. You signed up to help decide whether the idea underneath it was even right, and for months the honest answer was not yet.

You are also the reason we know what the actual problem is. When I asked each of you at intake what the hardest part of your process was, twenty-two teams gave me a version of the same answer: someone on the team kept a private spreadsheet whose only real job was settling arguments about what a customer had actually said. That finding is in the launch materials now, described in general terms, unattached to any of you by name. It should be attached. It came from your Friday meetings, your ticket queues, and your chat threads, not from a survey we ran on strangers. The announcement cannot carry that and still be readable to someone who has never used the product. This letter can.

More than one of you wrote back that week in March to say some version of the same thing: keep going, this is still better than the spreadsheet. I do not have the right to publish those messages. I do have the right to tell you they are the reason the scoring works the way it does today, and the reason I am not willing to let today’s launch quietly erase where it came from.

That is also why this is a public letter and not a private email. A private note disappears the day I get busy, and three quarters from now a pricing change or a new process could touch the twenty-two of you exactly the way it touches someone who signs up this afternoon, with no record that we ever said otherwise. Publishing this means the next person who joins Tidemark, and any reporter who calls this week, reads the same sentence you are reading: you got here first, and that has a cost attached to it that this company has to keep paying.

Here is what today changes and what it does not. The public price list on tidemark.io starts fresh for everyone who signs up from this morning forward, including whatever the ninety-day usage review decides about the free plan. It does not touch what any of you are already on. Everyone else now reaches us through launch@tidemark.io and the eight help articles that went live this morning; you still reach me directly, the same as you have since January. And in one week, July 7, the twenty-two of you sit down with us again, not the press, not the waitlist, to tell us what the ranked output still gets wrong. We set that meeting on the calendar before we set the launch date, and it is not moving.

What I am asking of you in return is not new. Keep telling us when the ranking gets something wrong, the same blunt way you told us in March. Show up on the seventh. And if any part of what I have written here stops being true, if the direct line goes quiet or the price moves or the seventh quietly gets rescheduled into nothing, say so, publicly, the same way I am saying this now. You have more standing to hold this company to its word today than you will a year from now, once the twenty-two of you are a smaller fraction of who uses this. Use it while it is sharp.

With the thanks the announcement had no room for,

Marisol Veen Head of Product, Tidemark Portland, Oregon

A personal year-end reckoning with a difficult year

An Open Letter to Meridian’s Former Funder

Submitted to The Civic Ledger as a public letter, and sent directly to your program office the same day.

Dear Funder,

I do not have a name to put after that word, and neither did the eleven volunteers who spent eighteen months building the broadband proposal you agreed to fund. For the life of the Meridian Community Broadband Initiative, from September 2023 until you withdrew in March 2025, “you” meant a program office we corresponded with by email and a decision that arrived, when it arrived, without anyone’s signature attached to it. I am writing because that absence turned out to matter more than I understood at the time, and I do not think I am the only coalition lead who has learned that the hard way.

I led that coalition: eleven of us, drawn from two library systems, a school district technology office, three neighborhood associations, two small regional internet providers, and a few residents with no institutional backing at all. We held a technically sound infrastructure proposal together for the full eighteen months, and held your confidence in it for just as long. Grace Halloran, a branch manager who gave a year and a half of her own time to this proposal, did that on the understanding that work this sound, sustained this long, would become something real. In March, you withdrew, and it did not.

I am not writing to relitigate that decision. You are entitled to change your priorities, and the coalition’s own account of what happened, already public, is that the ending was not a verdict on our work. What I am naming is what came with the decision and what did not. What came with it was a closure I then had to translate for eleven volunteers who deserved to hear it from someone with standing to explain it, and instead heard it from a person who was, like them, unpaid and no longer certain what he was allowed to promise. What did not come with it was a transition period, a named contact for their questions, or any sign that eighteen months of volunteer trust carried an obligation on your side that outlasted the money.

I have already done my part of this accounting. In February, I gave the coalition a complete written account of what I got wrong in how I managed the closure, including the month I sat on a signal that your priorities were shifting instead of telling them sooner. That account was private, because what I owed the coalition was private and specific to the eighteen months we spent together. This one is not private, because the gap I am naming here is not mine to close by myself. In September, I wrote to your program office directly and asked whether any exit standard exists anywhere in your process for coalitions like ours. I have not heard back.

The Civic Ledger’s editorial board has already made the structural version of this argument: that a funder who can exit on its own schedule, while the volunteers who built the proposal cannot exit at all, was never sharing risk in the first place, and that the fix belongs in the agreement itself, not in whatever grace a coalition lead extends afterward. I agree with that argument. I am turning it into a specific ask instead of a general one.

Put a minimum exit notice period and a named transition contact into the funding agreement for whatever coalition you convene next, before a single volunteer hour is logged against it. Tell the eleven people who built this proposal, in writing, whether that change is happening. And answer this letter, publicly or directly, on a timeline you set and then keep, which is the same standard I am now holding myself to. This one is public because the last one was not, and eleven volunteers had no way to see whether their questions had even been received. Anyone deciding whether to give your organization another year and a half of unpaid work can now watch whether this letter gets an answer, the same way I am watching whether the coalition’s did.

Marcus Delgado Former lead, Meridian Community Broadband Initiative I wrote your program office privately in September and heard nothing back. This is the same question, on the record now, because eleven people and the next coalition you fund are owed more than my silence matching yours.