Op-Ed

A short argued opinion piece for a publication that advances one clear position on a timely issue.

Op-Ed

An op-ed is a short argued opinion piece - typically 600 to 800 words - written for a publication’s readership to advance one clear position on a timely issue. The writer enters already holding a conviction; the work is to state it sharply, marshal a few well-chosen supporting points, and end on a call or implication. The form disciplines the writer: no meandering, no hedging, no comprehensive survey. One claim, argued concisely, for a readership that did not choose the writer.

The canonical structure is three moves: the lede (a claim or provocation that names the position and why this piece exists now), the body (two to four supporting paragraphs, each a distinct point drawn from evidence, experience, or reasoning), and the close (a call to action, a reframing, or an implication the reader can carry away). The hard word limit makes every transition load-bearing; an op-ed cannot hide a weak seam behind volume.

Canonical template

[Lede: the claim or provocation in one to two sentences. Name the issue and the position immediately.]

[Context: why this issue matters now - 1 paragraph]

[Point 1: first supporting argument or piece of evidence - 1 paragraph]

[Point 2: second supporting argument or evidence - 1 paragraph]

[Point 3 (optional): third supporting argument - 1 paragraph]

[Close: call to action, reframing, or implication. Land the piece in one to two sentences.]

When to use

Arguing a clear position on a timely public issue in a named outlet, building external credibility through a third-party publication, responding to a recent event or policy decision with a focused opinion, establishing a point of view for a bylined author on a contested question.

When not to use

When the topic requires nuanced exploration rather than a pre-held conclusion, when the goal is to inform or instruct rather than argue a position, when the writer wants to publish at their own length in their own venue without editorial constraints.

Pairs well with

columnist, journalist, candid, resolute, classical-argument

Often confused with

blog-post-long-form: A long-form blog post is a substantial web article of 1,500-3,000 words with a present and recognizable authorial voice; it can pursue a focused argument or a deeper exploration of a topic at its own pace. An op-ed is written for a third-party publication, holds to 600-800 words, and argues a single pre-held position from the first sentence. The blog post’s length lets the writer develop ideas gradually; the op-ed’s hard word limit and external outlet demand that the position be declared and defended without detour.

editorial: An editorial is the UNSIGNED collective opinion of a publication’s editorial board, speaking as we for the masthead and grounding its authority in the institution’s reported-fact and observed-pattern judgment - it forbids personal anecdote. An op-ed is SIGNED by an individual whose authority comes from their own stake, lived experience, or distinctive voice, and may build the argument on first-person anecdote.

Tells

• Leads with the claim or provocation in the first one or two sentences - no preamble or buildup
• A single arguable position held throughout - no hedging or both-sides framing
• Two to four body paragraphs, each a distinct point, not a wandering exploration
• Hard word limit observed: 600-800 words, with no digressions
• Written for a named publication’s readership, not the writer’s own audience
• Ends on a call, implication, or reframing - not a restatement of the argument
• Draws authority from the named author’s own stake, experience, or voice - first-person anecdote is allowed and often central

Anti-patterns

• Opening with background or context before stating the position - Op-ed readers are strangers; the first sentence must earn the next. Delaying the claim wastes the lede and gives an editor reason to reject.
• Hedging the position throughout to capture both sides or add nuance - An op-ed argues one position; hedging collapses it into a summary of the debate and abandons the stance the format exists to carry.
• Writing a substantial, multi-section exploration of 1,500-plus words in a conversational voice - which is how a long-form blog post works, as a substantial web exploration with a present authorial voice - and then cutting it down to 800 words - A long-form blog post is a substantial web article (1,500-3,000 words) with a present, recognizable authorial voice; the op-ed is written for a third-party outlet, holds one pre-held position from the start, and is conceived at 600-800 words. Trimming a blog post does not produce an op-ed; the op-ed must be structured as argument from the first draft.
• Adding a supporting evidence paragraph for every sub-claim until the piece exceeds the word limit - The word constraint is structural; one well-chosen anchor per point is the discipline. A piece that needs exhaustive evidence for every claim has become a brief or policy paper.

Failure modes

• Hammers the same claim in every paragraph rather than building a cumulative argument, turning the piece into a one-note polemic - Each body paragraph must advance a distinct point; if two paragraphs say the same thing with different words, collapse them and use the freed space to add a second supporting line of reasoning.
• Over-compresses for the word limit and tips into pure assertion - the claim is stated but never supported enough to distinguish the piece from a tweet thread - Even at 600-800 words there is room for two to three concrete anchors (an example, a figure, an observed pattern); if a draft has none, it is asserting rather than arguing and will not survive an editorial read.

Instruction

Write as an op-ed (600-800 words). Lead with the position in the first one or two sentences - do
not open with context, history, or a rhetorical question. The claim must be arguable, timely, and
clear before the third sentence. Structure the body as two to four distinct supporting points, one
per paragraph, each grounded in a concrete example, figure, or observation. Do not hedge the
position or present multiple sides - this is an opinion piece, not a survey. End with a call to
action, a reframing, or an implication the reader can carry forward. Stay within 800 words.

Template

See the Op-Ed template.

Related

Pairs well with

Columnist, Journalist, Candid, Resolute, Classical Argument

Avoid with

Instructional, Reverent, Pastoral

Often confused with

Blog Post (Long Form), Editorial

Examples

Whether the team should move to async-first standups

We Deleted Our Daily Standup. Yours Should Go Too.

By Jordan Ellis

Two weeks ago I signed a one-paragraph memo that deleted a recurring meeting from eleven engineers’ calendars, and it is the best process decision I have made as an engineering manager. If your team spans more than two time zones and you are still holding a daily synchronous standup, delete yours too. You do not need a year of debate to get there. Thirty days of data was enough for us.

I run an eleven-person engineering team at Fernbridge Software, split across four time zones: US Pacific, US Eastern, the UK, and India. Eighteen months ago we were a six-person team, and a 9am Pacific standup worked fine for the people in the room. We hired, the team spread across the map, and nobody redesigned the meeting to match the team we had actually become. It stayed fixed at 9am Pacific, which lands at 9:30pm for the three engineers who joined us from India. We told ourselves that was a minor inconvenience. It was not minor, and it did not fall on everyone evenly.

Our own Q1 numbers said what none of us wanted to say out loud: the India-based part of the team averaged 3.2 standups out of 5 each week, against 4.6 for everyone working on a US clock. For months we quietly treated this as an engagement problem and wondered, without saying it out loud, whether those three engineers cared less. They did not care less. They were being asked to sit through a status meeting after their kids were asleep, night after night, and eventually some of them stopped showing up. That is not a motivation gap. That is a design flaw, and it was ours to fix.

The people who could attend were not getting much out of the meeting either. We timed a month of our own standups: fourteen minutes on the clock, and by our own count, only about four of those minutes changed what anyone actually did that day. The other ten were status nobody needed delivered out loud. Worse, none of it stuck. We found three separate cases last quarter where an engineer burned over an hour rediscovering a bug a teammate had already solved and mentioned, once, in a standup nobody could search afterward. A meeting that leaves no record is not a coordination tool. It is a performance with a 9am curtain.

So instead of arguing about this in the abstract for another year, we ran a 30-day trial. We replaced the meeting with a three-field written update, posted to a shared Slack channel by 10am each person’s own local time: what shipped, what is in progress, what is blocked and who needs to see it. Someone reads the channel every morning and chases anything tagged. By the end of the trial, on-time posting had climbed from 78 percent to 85.5 percent, the median time from a flagged blocker to a real response had dropped to 18 minutes, and every one of our India-based engineers posted an update on every single weekday of the trial’s final two weeks. That had not happened once in this team’s history under the old system. We made the new format permanent on June 23. It was not a close call.

The objection I hear most is that a written update cannot replace the human contact of a daily call, and I do not think that objection is wrong. A few engineers said exactly this in their trial debriefs; they missed the small daily contact. But the fix for that is not keeping a status meeting alive as a stand-in for a relationship. We moved our old standup slot to a single 60-minute working session each week, built for actual discussion instead of status updates, and it has done more for how this team knows each other than five short calls a week ever managed. None of this required new software or a consultant, just a Slack channel, a pinned template, and someone willing to read it every morning. If your team is spread across more than two time zones and you are still holding a daily call because that is simply how it has always been done, run your own 30 days before you spend another year defending it. The math will make the argument for you. Ours did.

---

Jordan Ellis is an engineering manager at Fernbridge Software in Seattle.

Designing a sustainable morning routine

Your Morning Routine Is Not Broken. Your Environment Is.

Morning routine advice has the problem backwards. It keeps selling a longer ritual, more steps, more discipline, more things to do before coffee, when the one change that has actually worked for me is where my phone spends the night.

This matters right now because the morning routine has become its own genre: wake before dawn, cold water on the face, a gratitude page, a movement block, a green drink, most of it performed and increasingly filmed before anyone else’s alarm goes off. The advice keeps multiplying and, in my own experience and in every honest account I have read, the completion rate keeps failing to keep pace with it. Something in the model is wrong, and I do not think the answer is more ritual. I have spent the last year testing that claim on myself, which is the only trial I can actually vouch for, and the results have been narrower and more useful than the genre usually admits.

I know because I tried the willpower version first, three separate times over the past year. The entire plan was simple: do not check the phone before your feet hit the floor. Each attempt lasted four to six days before it quietly stopped, and not because I ran out of discipline on day five specifically. That is not a character flaw. It is what happens when a plan depends on a finite resource being available at the exact moment temptation is highest, which for me was always seconds after opening my eyes. A rule with nothing built to replace it is not a routine, it is a vacuum, and a vacuum gets filled by whatever object is closest and easiest to reach, which in my case was always a phone within arm’s reach of the bed. Willpower is a resource you spend making a decision. A phone in the room is a decision you have to keep winning, every morning, indefinitely. Eventually you stop winning.

The change that has actually held, one month into the current version, is not a new ritual at all. It is a location. The phone now charges in the kitchen, face down, and stays there through a short sequence: water, light, a walk or a stretch, then ten minutes with a paper notebook, roughly an hour end to end, nothing that needs equipment or a subscription. That single rule has held at a 93 percent rate over 30 days, ahead of every other piece of the routine by a wide margin, including the parts I like more. Compare that to the rest of the routine, which held at a little over three quarters across the same 30 days, still good, but nowhere near as durable as the one piece that removed a choice instead of adding one. It did not take more discipline than the rest. It took none, because there was nothing left in the room to resist.

This is also why the routine stayed small on purpose. I tried the ambitious version first: a 90-day commitment, a longer list, a bigger promise to myself. I quit on day 11. Small is not the same as unambitious. It is just the only size that survives an actual week. The version I am still running was scoped to 30 days with a checkpoint built in, and it survived a bad cold, two trips, and one very ordinary morning of just not wanting to. My spouse and the friend who agreed to hold me accountable both signed off on the design before I started. That mattered less, in the end, than the boring mechanical fact that the phone was no longer in the room.

None of this required an app, a subscription, or a philosophy. It required moving one object to a different room and treating the decision as already made before the day could ask me to make it again. If your mornings are not working, the fix is probably not a longer list; it is one fewer decision to defend before you have had any water. The routines that survive are not the impressive ones. They are the sustainable ones, and sustainable, it turns out, just means there was nothing left to decide. Move the phone. See what happens to the rest.

Choosing Postgres vs DynamoDB for a new service

In Defense of the Boring Database

By Ana Rivera

This month my team spent two days close to adopting a second production database, for reasons that sounded airtight in the room and mostly evaporated the moment we asked who would carry the pager for it. We did not adopt it. I think that near miss says more about how engineering teams should choose data stores than the decision itself does.

Every growth-stage team eventually sits in this meeting. A new feature needs a new place to put its data, someone runs the access-pattern numbers, and the numbers point toward a database the team has never operated in production. At Lattice Notify the feature was a real-time notification system: about 500,000 events a day at launch, with a scenario for ten times that within twelve months if a partnership deal we are negotiating with Slack closes. The candidate that fit the access pattern on paper was DynamoDB, built for exactly this kind of write-heavy, point-lookup traffic. The candidate we already knew how to run under production pressure was Postgres. We picked Postgres, and I want to argue the reasoning generalizes well past our one decision.

Start with the question access-pattern analysis never asks: who operates this at two in the morning? My team runs a four-person on-call rotation across eight backend engineers. Every additional production datastore is not a line item, it is a second runbook, a second alerting surface, a second set of failure modes someone has to hold in their head while half awake. Marcus, one of our senior engineers, made a genuinely strong technical case for DynamoDB’s fit with our access pattern, and he was not wrong about the fit. He was answering a narrower question than the one that mattered. The database that suits your access pattern on a whiteboard and the database your team can actually operate under production pressure are two different evaluations, and treating them as one is how teams end up debugging an unfamiliar system during an incident instead of during a training exercise.

Second, be suspicious of any architecture decision that is really being made on behalf of a future you do not have yet. Our case for the DynamoDB-shaped future rested on a partnership deal that had not closed. Ten times the load is a real scenario worth planning for, but it is a scenario, not a commitment, and a scenario should not get an equal vote against the traffic we already know we are building for. We wrote the decision down with a number attached instead of a forecast: 5 million events a day, and when we cross it, we revisit the choice with real data. That threshold does more work than another round of debate about whose growth model is more credible, because it turns an argument about the future into a metric we can simply watch.

Third, weigh reversibility honestly, in both directions. If we outgrow Postgres, we lose 3 to 6 weeks to a migration we can plan for, on a system we understand well enough to know exactly when the wall is coming. If we had adopted DynamoDB and it turned out wrong, the more expensive loss would never have shown up on a project plan at all: a team that spent its scarce learning capacity on a second database instead of on the product. Operational knowledge is not one engineer’s skill, it is a team’s accumulated runbooks, tuned alerts, and rehearsed failure modes, and rebuilding that for a new datastore costs closer to a year than a sprint. That asymmetry, not the access-pattern comparison, is what should decide most of these meetings.

The next time your team is choosing a database, ask the access-pattern question last, not first. Ask who carries the pager, ask what you actually know today instead of what you are forecasting for a deal that has not signed, and pick the tool that turns your team’s existing competence into an advantage. The boring answer is usually the disciplined one.

Ana Rivera is the tech lead for the notification service at Lattice Notify.

Telling stakeholders a committed feature is being cut this quarter

‘Soon’ Is the Most Expensive Word in Product Management

By Maya Chen

When a product team has to break a roadmap promise, the standard response is to soften the language: “we’re still committed,” “more details soon,” “stay tuned.” That instinct is backward. The specific, falsifiable version of bad news is kinder than the vague, comfortable one, and it is the only version that keeps a customer’s trust intact.

A few weeks ago I told four enterprise customers that Insights, an in-app analytics dashboard we had committed to ship this quarter, would not make the date we gave them. A mandatory billing-system migration ran long and consumed the engineering capacity we had set aside for the dashboard, and by the time that became clear, finishing both on schedule was no longer possible. This is not a Meridian problem. Every product organization I know eventually has this quarter, the one where a dependency outside the roadmap eats the calendar and someone has to deliver the news. The mistake most of us make is not the broken commitment itself - commitments break for real reasons often enough that customers have learned to expect it - the mistake is in how we talk about it afterward.

Vague language feels safer to write because it commits you to nothing you can later be caught having gotten wrong. “Soon” cannot be falsified on a specific Tuesday, so it never has to be defended in a follow-up email. But that safety is bought entirely at the customer’s expense. A customer who hears “soon” cannot plan around it, cannot tell their own boss when the gap will close, and cannot decide whether to build a workaround or simply wait. They are left holding the uncertainty that we, the team who made the promise, were unwilling to hold ourselves. Every week that passes without a real date is a week we have quietly handed our own discomfort to someone who did nothing to deserve it.

Specific language is harder to write because it exposes you. Once you say Q1 2027, or March 13, or “here is exactly what you get in the meantime,” you have handed the reader a yardstick to measure you against later, in public, on a date you chose. That exposure is precisely why the discipline works. A team willing to commit to a falsifiable claim is telling the customer something true about itself that has nothing to do with the content of the claim: we did the work to know this, and we are willing to be held to it. Vagueness can be produced by a team that has not yet figured out its own plan. Specificity cannot be faked past a customer who is paying attention, which is exactly the customer you are trying to keep.

What we told those four customers was not comfortable, but it was exact. The dashboard moves to Q1 2027, with a target release of March 13. Before the end of this quarter, they get a CSV export of the same underlying data we will eventually surface in the dashboard itself, so they are not waiting empty-handed while it gets rebuilt - a smaller thing than what we promised, and we said so plainly instead of dressing it up as most of what they wanted. Nobody on those calls thanked us for the delay. Two of the four were angry, reasonably, and said so. But every one of those conversations ended with a plan the customer could act on: a real date, a real interim deliverable, and a real person to call if either one slipped. That is the only thing a delayed roadmap update actually owes anyone.

The next time your team has to deliver news like this, resist the sentence that protects you and reach for the one that could be proven wrong. Give the date, not the feeling. Your customers were never going to be happy that the feature slipped - the only thing you still control is whether they can plan around you anyway.

Maya Chen is the product lead at Meridian, a platform for account, billing, and usage management.

Getting a new engineer productive in their first two weeks

A Wiki Page Is Not an Onboarding Plan

By Mei Chen

Every engineering team I know says its onboarding documentation is thorough. Almost none of them can tell me who is personally responsible for a new hire’s first two weeks - and that missing name, not the wiki’s quality, is why so many new engineers spend a month feeling like a guest in their own job.

The instinct to solve onboarding with documentation alone is easy to understand. Docs scale and a senior engineer’s attention does not; a wiki page costs nothing to maintain next to two weeks of a buddy’s focus. Hiring is picking back up across the industry, and lately I keep hearing the same proposal in meeting after meeting: write the runbook once, point new hires at it, and let the team get back to shipping. I do not think it works. I have just spent two weeks watching the alternative in practice, and the difference was not subtle.

When Priya Rao joined our backend team, we did not hand her a login and a link. We assigned her a named buddy, Arjun Nair, from her first morning, and the value showed up not in what she read but in what she could ask. Documentation answers the questions a writer thought to anticipate. It cannot tell a new engineer which part of the system actually matters this week, or which failure mode is common enough to worry about and which one is a once-a-year edge case nobody has hit since the service launched. Arjun could answer both, in real time, because he was there to be asked. A wiki page is a monologue. A buddy is a conversation, and a new engineer does not yet know which questions to bring to a monologue.

The second failure of documentation-only onboarding is timing. Read-and-absorb plans leave a new hire to decide for herself when she feels ready to contribute, and that feeling tends to arrive late, if it arrives at all - I have watched engineers go three or four weeks without shipping anything real, and by then how the team sees them has already been decided by the silence. We chose the opposite. Priya’s first production change was scoped before she started, so real work was waiting for her rather than something she had to go find and volunteer for. She traced a live request through our systems in her first week and had a change reviewed and deployed before her third week began. Nobody was guessing when she would be ready. We had already decided.

Advocates of the documentation-only approach are right about one thing: Arjun’s time was not free. He gave up real hours across those two weeks that he would otherwise have spent on his own work, and that is a genuine cost sprint planning has to absorb rather than pretend away. But I do not believe that cost disappears when you replace a buddy with a wiki page. It just moves, unmeasured, into the weeks a new hire spends stuck and unsure whether her question is worth interrupting someone for. Cutting the buddy does not shrink the cost of a confused new hire. It only removes the one person accountable for noticing. There is a second return on that cost a wiki page cannot produce at all: by the end of the two weeks, three of Priya’s teammates had started conversations with her that had nothing to do with the onboarding plan. Nobody schedules that. It happens because a new hire who has been walked in by a real person starts acting like she already belongs, and a team responds in kind.

If your onboarding plan is a link to a wiki space, you have not eliminated the need for a buddy. You have only made sure no one owns being one. Name a person before the new hire’s first day arrives, and let the documentation do the smaller job it is actually suited for: backup, not the plan itself.

Mei Chen is the Onboarding Program Lead for Backend Services at Northlane Systems.

Writing to thank a mentor who shaped your career

Sponsorship, Not Mentorship, Is What Actually Builds a Career

By Sable Marchetti

Every mentorship program I have seen rewards the wrong behavior: it trains managers to give advice, when the only thing that reliably changes a career is a manager willing to spend her own credibility on someone who is not ready yet.

It is review season again, which means most companies are asking managers to rate their reports and, almost as an afterthought, to flag who is ready for more. In my experience that question gets answered by comfort, not evidence. Managers name the person who requires the least oversight, because that person is the safe bet on their own record, not the person who would benefit most from being trusted with something larger. I have made that safe call myself, more than once, and told myself it was prudence. It almost never is. Most performance systems do not ask managers to name who they were willing to risk something for, so most managers never learn that this is the actual job.

I know this because someone carried that risk for me. A decade ago, in my second year at the company, my manager, Dana, put my name forward to lead a cross-functional systems rebuild with a six-month timeline and real visibility to people well above both of us. I had never run anything close to that scale, and I told her so. She nominated me anyway, fully, not as a co-lead with someone senior quietly holding the actual authority. She stayed close for the first stretch: answering questions, asking sharper ones back, naming what I was not yet seeing. Somewhere around week three I was certain I had made a visible, expensive mistake, and I went to her ready to hand the whole project back. She did not take it. Then she stepped back further, even when stepping back was slower than simply giving me the answer herself. When I made a call I later had to reverse, she let me reverse it. If the project had gone badly, the organization would not have remembered that I was inexperienced. It would have remembered that she vouched for someone who was not ready.

That is the part the word mentorship hides. Advice costs the person giving it almost nothing beyond time, and it can be declined without consequence. Sponsorship is different: it is a senior person spending her own standing on another person’s untested judgment, in public, before the evidence exists to justify it. Dana absorbed months of exposure so that I could learn what accountability actually feels like, which is not the same as being walked through a simulation of it. A name put in front of the people who matter cannot be quietly withdrawn.

I know the difference because I have since done both, and only one of them changed anything. Last month I put a report of mine forward for a scope she did not yet think she could carry. I stayed close for the first few weeks, answering the same question twice without minding, then made myself stop reaching for the parts that were going wrong. She fixed the one that mattered most without me. I recognized the restraint the moment I felt myself resist it, because I had watched Dana apply that same restraint to me and assumed, at the time, that it came easily to her. It does not. I know that now because it does not come easily to me either.

Dana, if you are reading this, you already know why it exists. Everyone else: stop measuring managers by who they protect, and start noticing who they are willing to name before the evidence is in - that is the only form of confidence in another person that has ever cost the person offering it something real, which is exactly why it works.

Sable Marchetti manages an engineering team and is still learning which parts of that job she inherited on purpose.

Reflecting on keeping a discipline of rest

A full day away from work each week is not a self-care indulgence you earn after clearing your list. It is a structural requirement for good judgment, and most people who could benefit from it have already talked themselves out of trying it.

More of our work than ever runs on the assumption that we are reachable: messages arrive continuously, task queues refresh in real time, and the person who answers fastest gets treated as the person who cares most. Against that backdrop, setting aside one full day a week and making it genuinely unreachable - no messages, no task completion, no checking - looks close to reckless. I understand the reaction, because I held it myself for years. My first attempt at a weekly rest day lasted six weeks before a deadline pulled it under, and it took eleven months before I tried again. I am now fourteen weeks into the second attempt, and what those fourteen weeks have shown me is worth more than the wellness-column version of this argument.

The case for the rest day is not moral, it is structural. Weeks I work straight through, without a full stop, cost me on the other side of the ledger: decisions take longer to reach, I redo analysis I should only have needed to do once, and my patience for a genuinely hard problem narrows to almost nothing by the end of the stretch. None of that shows up as a missed deadline. It shows up as a slow accumulation of worse judgment, easy to miss from the inside and obvious in hindsight. The weeks that include a real stop do not just feel better. They produce cleaner decisions on the other end, and I have enough weeks behind me now, with the stop and without it, to trust the comparison.

None of this is free, and I would rather be honest about the cost than sell the day as painless. Holding the boundary takes real mechanics: phone in a drawer at 8 p.m. on Saturday, out again at 6 a.m. the next morning, a window that reached ten hours this week, up from four the week before. One work message sat unanswered from Sunday afternoon into Monday without a reply drafted in my head, which had never happened before in this practice. And even when the hours hold, a background habit keeps running its own tally of whether the rest was worth it - the same productivity mindset the day is supposed to interrupt, showing up inside the day itself. Anyone who tells you this gets easy is selling something. What gets easier is trusting the pattern enough to hold the boundary anyway.

The predictable objection is that this is a luxury: not everyone can disappear for a day, and plenty of jobs and family obligations will not allow it. That objection deserves a real answer, not a shrug. What I have found is that the people around me notice the unavailability far more than they object to it, and the explanation, when I give one, takes more words than anyone expects it to. That reaction is itself the data point. We have built workplaces and habits where being reachable at all times is the unspoken default, and taking it back requires a decision made in advance, on purpose, not a schedule that quietly happens to allow for it. The obstacle most people run into is rarely their job. It is that they have never made the decision out loud.

Pick one day. Not a lighter day - a day that produces nothing you can point to and answers to no one until it is over. You will not feel ready for it, and readiness was never the prerequisite. The decision is.

Marking a long-serving colleague's departure

Two Months’ Notice Is Not a Knowledge Management Strategy

By Howard Thayer

Most organizations do not ask their most reliable employee to explain their reasoning until that employee is already walking out the door. I retired from Crestfield Group on June 27, after twenty-six years in the same job title, and the only reason my team learned most of what I knew is that I happened to give two months of notice instead of the standard minimum.

Two months is not long enough to hand over a career, but it is more warning than most organizations ever build into their plans, because nothing about a role like mine signals urgency. Operations Coordinator does not read as a strategic risk on an org chart. For twenty-six years, though, the vendor calls nobody else knew how to route, the incident escalations that did not match the documented runbook, and the questions from newer colleagues who had not yet learned who to ask all ran through me by habit rather than by design. No one scheduled time to extract that knowledge before my notice period began, because nothing about the title suggested there was anything to extract. That is not a failure by any one manager. It is the default, everywhere, unless someone deliberately decides otherwise.

Here is what two months actually bought us. Dana Reyes and Marcus Okonkwo sat with me across two sessions in May and June and built a runbook: the sequence for reading an alert when the automated system does not tell the full story, the escalation paths for our vendors, and four utility contacts that existed nowhere in any company system because I had maintained them personally, unasked, for years. Those four contacts matter most at two in the morning during an outage, not on a routine Tuesday, which is exactly when an undocumented contact list is most dangerous to be missing. We got that much down because we treated it as a project with a deadline. If my departure had been sudden, or if no one had thought to schedule those sessions, none of it would be written down today. A notice period is not a knowledge management strategy. It is a scramble that happened to work.

The part that never made it onto the runbook is the harder part. Colleagues have started compiling notes on how I worked with people who were stuck or panicking, and I am glad they have, but a written note is not the same as being asked a question by someone who has answered a version of it a hundred times and knows which follow-up actually matters. Two senior colleagues have agreed to informally carry that function forward. That is a reasonable fix. It is also, plainly, an improvisation, assigned in my final weeks by people doing their best, in place of something built deliberately over years the way I built it, without anyone having decided that I should.

None of this is particular to Crestfield Group. If you manage people, you likely already have your own version of what I was: someone who never chased a promotion, whose title never changed to reflect what they actually carry, and who therefore appears on none of the lists your organization uses to flag critical-person risk. Succession plans, compensation reviews, and headcount forecasts are built to notice titles and reporting lines. They are not built to notice the person everyone quietly calls first.

Do not wait for that person to hand you a resignation letter before you ask them to explain their reasoning, not just their procedures. Find them this week, while it still feels unnecessary. By the time it feels necessary, you will be lucky to get two months of warning, and you will not get even that unless the person leaving chooses to give it to you. I chose to. Do not build your continuity plan on the hope that the next one makes the same choice.

Howard Thayer retired in June 2026 after twenty-six years as Operations Coordinator at Crestfield Group in Hartford, Connecticut.

Marking the team shipping a hard, long project

Nobody Noticed We Rebuilt Checkout. That Was the Point.

By Yuki Tanaka

Two weeks ago my team finished a fourteen-month rebuild of our checkout system, and if everything went the way it was supposed to, you never noticed. That is not a failure of our communications. It is the only honest measure of the work, and it is exactly the kind of measure most organizations are not built to reward.

The checkout had been broken for three years in ways that cost real money every week: cart abandonment stayed elevated, session-state bugs and payment-step drop-offs bled revenue, and the system underneath it all had absorbed five years of emergency patches with no meaningful test coverage to catch what any of them broke. Two earlier attempts to fix it in place had already failed. Early last year we chose from three paths: keep patching for another eighteen months with no guarantee we would land anywhere better, replace the whole system in a single release window and hope it held, or build the new system alongside the old one and move traffic over gradually, cohort by cohort, starting at one percent, with the old checkout standing by the entire time as a working fallback. Priya, our engineering lead, put the case for the third option plainly: the only way to validate a system built to handle checkout load is to route real checkout load through it. We chose the expensive option, before a single line of the new system existed.

Here is what that expense bought us. In February, an engineer named Marcus Teel found a silent cart-state mismatch in staging that would have corrupted multi-item orders under split payment; catching it cost three weeks and pushed a March launch to April. In April, Jordan Osei found a race condition between the payment callback and the session store during the final dress rehearsal, rewrote the handler instead of patching around it in a weekend sprint, and cost eleven more days. Neither issue was caught by the automated test suite alone. Both were found because an engineer was reading real production traffic carefully enough to notice something wrong, which is only possible when real traffic is already flowing through the new system while the old one is still standing there to catch what falls through it. A single-cutover migration does not give you that option. It gives you one shot, and a rollback plan that has never been tested against real load.

That fallback was not theoretical, either. We exercised rollback twice, in October and December, and neither time did a customer feel it happen. But I want to be honest about the bill, because pretending the slow path is free is its own kind of dishonesty: two on-call rotations for fourteen months, two runbooks, a growing pile of session-compatibility shims, and a team that had to hold both systems in its head at once for over a year. Slow and safe is not a synonym for easy. It is a trade you make on purpose, and you keep paying for it every sprint until the day you finally don’t.

The hardest part of that year was not the engineering. It was that almost none of it showed up anywhere an organization usually looks for evidence of work. No feature shipped. No line moved on a roadmap slide. When Dani Rowe called a hold on the March date over a bug that was not yet fully understood, or when Sam Wickfield held the regression bar on June 9, with every hour of delay feeling enormous and the pressure to ship at its peak, those were the decisions that kept this migration a status update instead of an incident report. A commit count will never show you a hold that got called. It will only ever show you the ones that didn’t. An organization that only has language for what shipped has no language for the decision that kept something from breaking, and it will eventually stop making room for the people willing to make that call.

The next time a team you manage asks for fourteen months to build something you will never see, resist the instinct to ask what they will have to show for it. Ask instead who would be explaining the outage if you had said no, and give them the time before you need the excuse.

Yuki Tanaka managed the fourteen-month checkout migration described here and is the program manager who ran its dual-track rollout plan.

Arguing a public position on return-to-office

The Return-to-Office Debate Has Only Two Options. We Refused Both.

By Priya Ahluwalia

Every organization currently re-litigating its return-to-office policy is being handed the same two options: mandate everyone back full time, or let the ad hoc flexibility of the last few years harden into permanent policy by default. Both are wrong. I lead the working group that spent the better part of two quarters proving it, and I want to make the public case for the option nobody was offering us.

The reason this keeps resurfacing is that almost nobody actually wrote a policy when offices reopened. They wrote a placeholder called “flexible” and let each manager interpret it however the moment demanded. That ambiguity was survivable for a while. It stopped being survivable once two groups inside the same company started building incompatible expectations on top of it: leaders who wanted proximity back because they could point to specific coordination failures, and employees who had restructured their actual lives, housing, childcare, a partner’s job, around an arrangement they were told was durable. Neither group invented their complaint. Both are responding to something real, which is exactly why picking a side settles nothing.

Start with the case for shared space, because it is stronger than most remote advocates want to admit. I watched a disagreement that would have taken four minutes to resolve face to face take four days to resolve over a chat thread, for no reason other than the two people who needed to talk were never in a room at the same time. New employees absorb this cost hardest. Nobody schedules a meeting called “overhearing how decisions actually get made here,” and that is precisely the kind of orientation that used to happen by proximity and mostly does not happen at all now. When someone on our own team raised, unprompted, that junior colleagues seemed to be missing something the rest of us took for granted, we did not have a rebuttal. We had a gap to close.

Now the case for flexibility, which is not really about comfort, whatever the office-first argument likes to imply. We tested a five-day-in-office requirement against two consecutive hiring cycles before we backed away from it, and watched strong candidates outside commuting range decline before the first interview both times. That is not a hypothetical cost - it is a name on a list of people we needed and did not get. And the employees who had already relocated on the strength of an earlier flexibility commitment were not being sentimental when they pushed back on reversing it. They had made real decisions on the strength of what they were told. Treating that as an inconvenience to be managed rather than a promise to be kept is not decisiveness. It is a broken commitment wearing decisiveness as a costume.

Here is the part I most want other leaders to hear before they announce their own policy: stop calling the middle option a compromise. A compromise is what both sides walk away from unsatisfied, and a policy explained that way gives both camps permission to reject it on principle. What we landed on instead is two fixed anchor days a week, Tuesday and Thursday, where everyone who can reach an office is expected to be in one, and three days that are genuinely flexible, no approval required and no exceptions logged. That is not splitting the difference. It is deciding, on purpose, which problem each part of the week exists to solve. We spent nearly as long arguing about who inside the company owned that decision as we spent arguing about the decision itself - settle ownership before you settle policy, or you will re-litigate both at once.

If your organization is still stuck choosing between full return and full flexibility, notice what you are actually choosing between: two policies that have each already failed somewhere, quite possibly inside your own building. Pick a small number of anchor days and mean them. Protect them from individual opt-outs for at least a full quarter before anyone is allowed to renegotiate. Then design the rest of the week around trust instead of attendance. The binary was never the honest choice. It was just the one that required no design work, and design work is the part of this decision most leadership teams have been trying to skip.

Priya Ahluwalia leads the work-location policy working group at her company, where she spent two quarters building the anchor-day model described here.

Announcing a new product to an outside audience

Your Roadmap Doesn’t Have a Prioritization Problem. It Has an Evidence Problem.

By Marisol Veen

Every product team I have ever worked with owns a prioritization framework. Almost none of them owns a shared set of facts to run it on, and that gap, not a missing framework, is what turns roadmap meetings into arguments.

I am biased here. I lead product at Tidemark, a company that opens to the public today, and the argument below is the reason we built it. But I watched this pattern for years before I had a product to sell, across three companies and three different scoring systems, and all three failed the same way: the framework decided how to weigh evidence, and nobody had checked whether the evidence in the room was the same evidence in the first place.

Here is what that looks like in practice. Someone opens the meeting with “customers keep asking for X,” and the claim carries whatever weight the speaker’s seniority and recency give it. Someone else has a different list, pulled from a different support queue or a different sales call, and it does not match. Nobody is lying. Everyone is looking at a different, honest slice of the same customer base, and the meeting spends its first twenty minutes reconciling slices instead of deciding anything. Only then does the team apply its careful scoring rubric, to whichever list won the reconciliation fight, and call the result data-driven.

This spring we ran an early-access program with twenty-two small product teams, and at intake I asked each one the same question: what is the hardest part of your current process? I expected a range of answers. I got the same one twenty-two times, worded differently: someone on the team keeps a private spreadsheet whose entire purpose is settling disputes about what customers actually said. Not tracking the feedback. Reconciling competing memories of it. That spreadsheet is the evidence problem made visible, and it exists at nearly every team too small for a dedicated research function and too busy to notice it built one anyway.

The instinct when a roadmap meeting goes badly is to reach for a better framework: a heavier scoring rubric, weighted voting, a facilitator brought in to referee. I understand the instinct. A framework is something you can adopt in an afternoon and defend in a memo. Fixing the evidence underneath it is slower and less visible, so it keeps losing to the framework upgrade. But a better framework applied to contested, partial evidence does not resolve the argument. It launders it into something that looks like data.

What changes when a team fixes the evidence layer first is not the sophistication of the decision. It is the length of the meeting. The teams in our early-access group stopped opening their planning sessions by establishing whose list was real, because there was only one list, built from every source the team already used, and everyone had read it before they sat down. What was left was the conversation actually worth having: which true thing matters more, not which version of events gets to be true.

None of this is an argument against frameworks. Weigh requests by frequency, by revenue, by strategic fit, by whatever your team has agreed matters, once your team agrees on what was said and by how many people. Do that work first. If your last planning cycle spent its opening stretch relitigating whose feedback list was accurate, the fix is not a better rubric. It is a shared one, built before the next cycle starts, whether that means an afternoon merging spreadsheets by hand or a tool built to do it for you. Tidemark is the version we built, and it opens to anyone today. It will not be the only answer to this problem, and it does not need to be. It only needs to get your team arguing about the right thing.

Marisol Veen is head of product at Tidemark.

A personal year-end reckoning with a difficult year

Your Year-End Essay Wants a Lesson. Mine Doesn’t Have One.

By Marcus Delgado

December runs on a formula: hardship, then the lesson it taught you. I had a hard year, and I am refusing to supply the lesson, because I have come to think the demand for one is a quiet form of dishonesty.

This is the season these essays run, and by now the shape is so familiar that readers expect it before the third paragraph arrives: name the loss, then pivot to what it built in you. I understand the appeal. A resolved year is more comfortable to publish, more comfortable to read, and more comfortable to have lived. But I spent eighteen months leading the Meridian coalition’s community broadband proposal, which dissolved in March when the funder backing it withdrew, and I spent the second half of the year watching a six-year partnership with Celeste go quiet without the conversation that might have changed it. Neither has resolved into anything I would call a lesson. Rounding either one up to meet the genre’s expectations would cost me the one thing I actually have left from this year: an accurate account of it.

Here is the specific part, because a vague admission that the year was hard is exactly the kind of cover this genre rewards, and I do not want to hide inside it. In February, the funder behind Meridian’s proposal was already showing signs its priorities were shifting. I saw the signs and chose to keep eleven volunteers, people who had given a year and a half of their time, aligned around optimism instead of telling them what I was actually seeing. I told myself I was protecting morale. I was protecting a story about the project that I had gotten too attached to. The funder withdrew in March regardless, on a timeline the coalition had no chance to prepare for, and the choice to manage that narrative instead of surfacing the risk early is the part of the loss that was mine to own.

I did the same thing to the people closest to me, which is harder to say plainly. After the coalition dissolved, my partnership with Celeste started drifting in a way I told myself was ordinary distance during a hard stretch. It was not distance I was giving her. It was a conversation I was avoiding, and by August we had stopped speaking. A close friend, Theo, sent a message in April that I read and did not answer, for the same reason: answering meant naming something I was not ready to name out loud. Both situations are still open as I write this. I have not folded either into a redemption arc, because there is not one available yet, and inventing one would repeat the exact error, managing how things looked instead of facing what was true, that already cost me the coalition’s trust once.

That is the actual argument, not just my personal accounting: the pressure to produce a lesson by January is the same pressure that kept me quiet in February. Both ask you to manage how a hard thing looks before you have finished finding out what it actually is. I finally wrote an honest internal retrospective in September, and naming the pattern did not resolve it, it just made the avoidance visible enough to stop repeating it in the same form. I still owe the coalition a full written account of what happened, due in February. I still owe Theo an actual answer, due in January. Writing a tidy version of this year for public consumption now, ahead of either of those, would be the same narrative management again, just wearing an essay instead of a coalition update.

If your year was hard and it has not resolved, you do not owe December a lesson from it. You owe the people it affected an accurate account, delivered on their timeline instead of the calendar’s, and an accurate account is allowed to end without one.

Marcus Delgado led the Meridian coalition’s community broadband proposal for eighteen months before its funder withdrew this spring.