Blog Post (Long Form)
A substantial web article of 1,500-3,000 words - long enough to go deep, short enough to respect the reader’s time.
Blog Post (Long Form)
Section titled “Blog Post (Long Form)”Long-form blog posts occupy a specific territory: they go deeper than a quick take but stop before they become a whitepaper or essay. The format works because it has a conversational quality that whitepapers lack - the writer is present, the voice is recognizable, and the reader feels addressed rather than briefed.
Structure matters more in long-form than in short-form because the reader needs navigation. Headers every 300-500 words, a clear progression from setup to insight to implication, and an opening that immediately establishes the specific territory.
Canonical template
Section titled “Canonical template”[Title: specific, not generic]
[Opening: establishes specific argument and stakes - 2-3 paragraphs]
[Section 1 header][Content - 300-500 words]
[Section 2 header][Content - 300-500 words]
[Section 3 header][Content - 300-500 words]
[Closing: landing, not summary - 2-3 paragraphs]When to use
Section titled “When to use”Thought leadership, technical explainers, opinion pieces, narrative case studies, educational content.
When not to use
Section titled “When not to use”Quick updates, operational documentation, formal reports, anything requiring strict citation.
Pairs well with
Section titled “Pairs well with”columnist, friendly-mentor, candid, warm, diataxis-explanation, classical-argument
Often confused with
Section titled “Often confused with”whitepaper: A whitepaper sets a position-of-record in an invisible institutional voice backed by citation; a long-form blog post keeps a present, recognizable authorial voice and explores a topic rather than setting a record.
- A specific, non-generic title that names the angle, not the field
- An opening of 2-3 paragraphs that establishes the specific argument and stakes
- Section headers roughly every 300-500 words to give the reader navigation
- A clear progression from setup to insight to implication
- A closing that lands rather than summarizes - 2-3 paragraphs
- Substantial length (1,500-3,000 words) with a present, recognizable authorial voice
Anti-patterns
Section titled “Anti-patterns”- Attempting a comprehensive treatment of an entire domain instead of one focused argument - The “post” constraint still applies; a comprehensive survey drifts toward the confusable whitepaper, which sets position-of-record rather than exploring a specific angle.
- Writing in an invisible, institutional voice with rigorous citation as the backbone - That is the whitepaper stance; the long-form post works precisely because the writer is present and the reader feels addressed rather than briefed.
- Ending with a recap that restates the section headers - The closing is the lasting impression; a summary wastes it, and the format explicitly asks the ending to land, not to summarize.
Failure modes
Section titled “Failure modes”- Pads with filler - throat-clearing, restatement, and digression stretch the piece to hit the word count rather than to go deeper - Length should come from depth, not volume; if a section does not advance the specific argument, cut it even if the post then runs short of 1,500 words.
- Over-navigates - so many headers and signposts are added that the prose fragments into a skimmable outline with no continuous thread - Headers exist to aid a reader who is already reading; if removing a header loses no meaning, the section was too thin to deserve one.
Instruction
Section titled “Instruction”Write as a long-form blog post (1,500-3,000 words). Establish the specific argument or questionin the opening - not the topic, the specific angle. Use headers every 300-500 words to give thereader navigation. The structure should move from setup through insight to implication. Theopening must earn the reader's next 1,500 words immediately. The closing should land - notsummarize. Give the reader something to carry away. Conversational but substantial - present invoice, deep in content.Template
Section titled “Template”See the Blog Post (Long Form) template.
Related
Section titled “Related”Pairs well with
Section titled “Pairs well with”Columnist, Friendly Mentor, Candid, Warm, Diataxis Explanation, Classical Argument
Avoid with
Section titled “Avoid with”Often confused with
Section titled “Often confused with”Examples
Section titled “Examples”- Should we adopt async-first standups?
- How to start a morning routine
- How to choose between Postgres and DynamoDB for a new service
- Telling stakeholders a committed feature is being cut this quarter
- Getting a new engineer productive in their first two weeks
- Writing to thank a mentor who shaped your career
- Reflecting on keeping a discipline of rest
- Marking a long-serving colleague's departure
- Marking the team shipping a hard, long project
- Arguing a public position on return-to-office
- Announcing a new product to an outside audience
- A personal year-end reckoning with a difficult year
Your Daily Standup Is Solving the Wrong Problem
Section titled “Your Daily Standup Is Solving the Wrong Problem”Three engineers on your team are joining your 9am standup at 9:30pm their time. They have been doing it for a year. You have noticed they attend less than the US-based engineers. You have probably assumed it is engagement or discipline. It is neither. It is 9:30pm.
The daily standup is one of the most persistent rituals in software development, and one of the most misunderstood. Most teams that run standups believe they are running a coordination meeting. What they are actually running is a presence ritual with some coordination features bolted on. Understanding the difference is what will help you decide whether to change the format - and if you change it, how to do it without breaking what actually matters.
What a Standup Is Actually Doing
Section titled “What a Standup Is Actually Doing”The synchronous standup has two functions that are usually bundled together.
The first is status visibility: who is working on what, what is blocked, what dependencies are about to collide. This is the explicit purpose. A well-run standup surfaces blockers early, catches coordination problems before they become delays, and keeps the team’s work visible to everyone on it.
The second is social presence: the daily act of gathering, of being in a shared moment, of saying “I am here and so are you.” This function is rarely named, but it is real. Teams that have daily standups feel different from teams that do not - there is a rhythm, a sense of shared forward motion, that does not come from the status itself but from the daily gathering.
The problem with synchronous standups for distributed teams is that they impose a coordination overhead to serve the presence function - and the coordination function can be served more efficiently with a different tool.
What Async Standups Do Better
Section titled “What Async Standups Do Better”An async standup is a structured written update posted to a shared channel. The format that works best is simple: what shipped in the last 24 hours, what is in progress today, what is blocked or at risk. Blocked items include a direct @mention of the person who can help.
Three things happen when you move from synchronous to async that are genuinely better than the meeting.
The information persists. When @priya posts at 8am India time that the auth service is throwing a 401 on a specific endpoint, that post is there when @dan starts his day in California three hours later. The engineer who hits the same 401 at 2pm can search the channel and find Priya’s diagnosis. In a synchronous standup, the same information evaporates after the meeting unless someone wrote it down. Nobody wrote it down.
Blockers reach the right person faster. In a synchronous standup, a blocker reaches the person who can resolve it only if that person attended the meeting and made a note. In an async channel, the @mention sends a direct notification. The blocker routes itself.
Everyone participates on a schedule that fits their life. The India-based engineer posts at 8am their time. The west coast engineer posts at 9am their time. Nobody is joining a meeting at 9:30pm. The team’s work is visible to everyone, and everyone contributed on a schedule that was reasonable for them.
What Async Standups Cannot Replace
Section titled “What Async Standups Cannot Replace”Here is where most writing about async standups stops being honest: the social presence function does not transfer.
A written update in a channel is not the same as being in a room together, or even a Zoom call together. The daily standup, whatever its coordination failures, created a shared moment - a daily rhythm of gathering that built team fabric over time. Async channels do not do this. You can build warmth and personality into your posts, but the shared-moment feeling does not survive the format change.
This is the real reason some teams switch to async standups and feel more fragmented three months later. The coordination problem is solved. The presence problem is worse.
The teams that get this right do not choose between synchronous and async. They separate the two functions and handle them with different rituals. The async standup handles coordination - status, blockers, visibility. A weekly working session handles presence - a synchronous meeting that exists explicitly for collaboration and connection, not status reporting.
How to Make the Switch
Section titled “How to Make the Switch”The structural change is simple. The adoption challenge is getting the team to post consistently and read attentively.
Start with a pinned template in your standup channel. Three fields. Ship it on Monday. Ask for updates by 10am local time. The team lead reads the channel at the start of their day and responds to blocked items within 30 minutes. That commitment to reading and responding is what makes the channel feel alive rather than a place where updates go to be ignored.
The first two weeks will be awkward. Engineers will post and wonder if anyone read it. Some will miss days. Hold the norm firmly and gently: the format only works if everyone participates. At week three, most teams find their rhythm.
The synchronous meeting does not disappear - it transforms. A 60-minute Thursday working session, reserved for discussion that needs real-time exchange. Not a standup. Not status. A session for the work that benefits from being in the room together.
Run it for 30 days before you decide whether it is working. Track blocker resolution time, participation rate, and do a short team survey. If it is not working, you will have data on what to adjust. If it is working, you will know why.
The Thing That Actually Changes
Section titled “The Thing That Actually Changes”The shift to async standups is not really about format. It is about what you believe a distributed team owes each other.
The synchronous standup says: we owe each other shared presence, daily, at a fixed time, regardless of what that costs people on the edges of the timezone map. The async standup says: we owe each other visible work and honest blockers, on a schedule that respects the fact that we live in different places.
Both are forms of accountability. The question is which form fits the team you actually have - not the co-located team the standup was designed for, but the distributed team that exists now, on four continents, at four different local times.
The ritual that serves that team is not the one you inherited. It is the one you build.
The First Hour Is the Whole Day
Section titled “The First Hour Is the Whole Day”For most of the past year, I have been losing the same forty-five minutes every morning, and I did not realize it was a recurring loss. I would wake around 6:30, reach for my phone in the dark, and surface forty-five minutes later with no memory of what I had read but a vague low-grade tightness across the shoulders. The day had begun without me. Or rather, the day had begun in a register I did not choose, and the rest of it was spent trying to climb back into a register I did.
This is not a productivity essay. There is enough of those. This is a small report from someone who tried, finally, to design the first hour deliberately, and who is now five weeks into the experiment and willing to say something modest about what changed.
What I tried to fix
Section titled “What I tried to fix”The problem was not really “phone use.” The problem was the absence of a default. When I wake up, my brain wants a thing to do. It does not particularly care what the thing is. For years the default was “check Slack,” because Slack was within arm’s reach and the act of checking gave me a sense, however illusory, that I had begun.
You cannot remove a default. You can only replace it. This was the part I had been getting wrong.
The four modules
Section titled “The four modules”I settled on four small things to do between 6:30 and 7:30am, in this order:
-
Water. Eight ounces, room temperature, before anything else. The point is less hydration than ritual. The first physical action of the day is one I chose.
-
Light. Ten minutes outside, or if the weather is hostile, next to the biggest window in the house. This one has the most published science behind it and the least immediate emotional payoff. I do it anyway.
-
Movement. Fifteen minutes. A walk, some stretching, occasionally bodyweight squats and pushups if the legs feel willing. Nothing that requires changing clothes twice or that I would post to Strava.
-
Planning. Ten minutes with a paper notebook. Three lines: what matters today, what I will protect, what I will let drop.
Total time: roughly forty-five minutes. The phone, meanwhile, sits in the kitchen, plugged in, face down. It is allowed to come back into my hand at 7:30am, when the family wakes and the day formally starts.
The phone is not the enemy. The phone is a vacuum cleaner. If you do not give your morning something to be, the phone will gladly take the empty space.
What I expected
Section titled “What I expected”I expected to feel calmer. I expected to be more productive at work. I expected, on some level, that the routine would be the kind of thing I could turn into a small lifestyle brand if it went well.
What actually happened
Section titled “What actually happened”The calm came, but it came differently than I had imagined. It was not that the mornings themselves became serene. Some of them are still chaotic, particularly the ones when a child wakes up early and the choreography collapses. The change is subtler. The change is that on a chaotic morning I now have something to return to. The routine is a baseline, and a baseline is what I had been missing.
Productivity at work is harder to evaluate. I think I am better. My colleagues have not commented, which is either a sign of nothing or a sign that I had been overestimating how visible my fatigue was to anyone else.
The lifestyle brand fantasy has dissolved entirely, which I count as a victory. The routine got smaller and more boring as it took hold. It is mine now in a way that does not require an audience.
A note on failure
Section titled “A note on failure”I have missed nine mornings out of thirty-five. Twice I was traveling. Three times I was sick or a child was sick. The other four were just failure - mornings when I woke up, reached for the phone anyway, and was halfway through the email queue before I remembered the design. The routine does not punish me on those days. I just start the next morning at the beginning. The fact that there is a “beginning” to start at, and not a vague aspiration to feel better, is most of the gift.
If you want to try this
Section titled “If you want to try this”You probably do not need my four modules. You need any four modules, chosen by you, that you can stand the sight of at 6:30am. The order matters less than the existence of an order. The content matters less than the fact that you wrote it down before you needed it.
Pick a start date. Move the phone to a different room tonight. Set out the notebook. Tomorrow, when your hand reaches for the device that is no longer there, it will find the glass of water instead. That is the entire trick.
The first hour is not separate from the rest of the day. It is the rest of the day, in miniature, rehearsing.
Why We Picked the Boring Database (Again)
Section titled “Why We Picked the Boring Database (Again)”There is a particular meeting that recurs at every growing startup. A new service needs a new datastore. Two engineers, both right in their own way, arrive with opposing recommendations. The PM wants a decision by Friday. The tech lead leans toward the thing the team already knows. The senior engineer leans toward the thing that fits the access pattern. Everyone in the room has read the same blog posts. Nobody has the answer.
We just had that meeting at Lattice Notify. The new thing was our real-time notification system. The two candidates were Postgres (which already runs our monolith) and DynamoDB (which our senior engineer Marcus, with some justification, called “the obvious choice for this access pattern”). The decision was due in three days. I want to write about how we made it, because I think the way we made it is more useful than the answer we landed on.
The actual question is not the question
Section titled “The actual question is not the question”The framing on Monday was “Postgres or DynamoDB for the notification service.” That is not the actual question. The actual question, once you sit with it for an hour, is something like: which of these two options has a smaller blast radius if we are wrong, given the team we have, the growth we expect, and the time we have to recover?
Marcus is right that DynamoDB fits the access pattern. We are writing 500K notification events per day at launch, with potential for 5M if the Slack-partnership deal lands. The reads are mostly point lookups by user. This is exactly what DynamoDB was designed for. If we were a team of 80 engineers picking from a clean slate, this would be a one-meeting decision.
We are not that team. We are 8 backend engineers with a 4-person on-call rotation, one production database we know how to operate, and a monolith that the new service will need to query. Ana, our tech lead, has been operating Postgres at our scale for three years and has a runbook in her head for every failure mode we have hit. Marcus has read the DynamoDB docs and built one personal project on it. The team is asymmetric on this dimension by a factor of ten.
The actual question is whether the access-pattern fit advantage of DynamoDB is larger than the operational capacity disadvantage of adopting it. And the only honest answer is: probably not, but we have to think about it carefully, because the cost of getting this wrong in the other direction is also real.
Cost of being wrong, in both directions
Section titled “Cost of being wrong, in both directions”Here is a framing that helped us. If we pick Postgres and we are wrong, what does that cost? We hit a scaling wall sometime in the 12-month window if growth accelerates, and we do 3 to 6 weeks of migration work to move the notification system to a different store. We have the data to know when we are approaching the wall. We have the team to do the migration.
If we pick DynamoDB and we are wrong, what does that cost? We discover that cross-database queries against the user data in the monolith are harder than we estimated, we discover that the 4-person on-call rotation cannot reliably debug DynamoDB throttling at 3am, and we have no rollback because we built six weeks of product on top of it. The cost is similar in weeks but worse in confidence: we have a team that has learned a tool that did not serve them.
Both are recoverable. Neither is free. The interesting fact is that the recovery cost of being wrong about Postgres is more predictable than the recovery cost of being wrong about DynamoDB, because we have done one before and not the other. Predictable recovery is itself a form of insurance.
Why “the team already knows it” is a load-bearing argument
Section titled “Why “the team already knows it” is a load-bearing argument”There is a class of engineering decision where “we already know how to operate this” is treated as a soft argument. It is presented as conservative, risk-averse, maybe even a little embarrassing - the implication is that a more sophisticated team would just learn the new thing. I want to push back on this framing.
Operational knowledge is not a static property of a person. It is a network effect across a team. Ana knowing Postgres at our scale is not just Ana’s personal expertise; it is the runbooks she has written, the alerts she has tuned, the failure modes the on-call rotation has rehearsed, the monitoring dashboards that already exist, and the muscle memory of every engineer who has paged into a Postgres incident. Replacing that network with DynamoDB is not a 2-week learning curve. It is a year of rebuilding it.
At a 50-person Series B, your operational capacity is one of the scarcest things you have. Spending it to adopt a new database needs to clear a high bar. “Better access-pattern fit” is a real argument, but it is the kind of argument that wins at 80 engineers, not at 8.
What we actually decided
Section titled “What we actually decided”We picked Postgres. We are building the notification service on a new schema in the existing primary cluster, with a queue backed by pg_notify and a jobs table. We have a documented revisit threshold (5M events/day sustained) at which we will pause and ask the question again, with the data we have by then.
Marcus is fine with this. Not because he changed his mind on access-pattern fit, but because he agrees that the operational argument is the load-bearing one given who we are right now. Priya has the decision for sprint planning. We will ship to production in three weeks.
The interesting thing about this decision, in retrospect, is how little of it was about Postgres or DynamoDB. The technical comparison took an hour. The operational comparison took two days. The hard part was getting honest about what kind of team we are, and what kind of mistakes we can afford to recover from.
If you are in a meeting like this next week, that is the question I would put on the whiteboard first. Not “which database fits the access pattern.” That one has an answer in a docs page. The harder question is: which of these mistakes can we recover from? Pick the database whose failure mode you already know how to survive.
What We Owe You When a Commitment Changes
Section titled “What We Owe You When a Commitment Changes”We promised you Insights this quarter. We are not delivering it this quarter.
That sentence is the hardest thing to write in this post, so let’s get it out front where it belongs. Insights - the in-app analytics dashboard we committed to ship in Q3 - is moving to Q1 of next year. If you are on our sales team reading this, or if you are a customer who asked us directly about Insights and heard us say “Q3,” you have every right to be frustrated. We heard you, we said yes, and now we are saying something different.
What we want to do in this post is give you the full picture: what happened, what we decided, what we are shipping as a bridge, and when you can actually count on Insights. Not because transparency is a good brand posture - that framing makes the whole thing feel managed - but because you made decisions based on what we told you, and you deserve to understand what changed and why.
The Migration That Changed Our Quarter
Section titled “The Migration That Changed Our Quarter”In May, our legal and finance teams flagged a compliance requirement in our billing infrastructure that we could not defer past the end of Q3. The specifics are operational, but the short version is that our billing system needed to be migrated to a new provider to satisfy a contractual obligation with one of our payment processors. This migration was not discretionary. If we did not complete it by September 30, we would have been in breach of terms that affect every customer’s ability to pay us.
We started the migration in early June with what we believed was a solid timeline. Our infrastructure team estimated six weeks of work. That estimate turned out to be wrong in the way that estimates about legacy billing systems are often wrong: we encountered undocumented dependencies and data integrity issues that we could not have anticipated without doing the work. By mid-July, it was clear that the migration was going to consume the engineering capacity we had planned to spend on Insights.
At that point we had a decision to make. We could push the migration to the side and try to ship Insights on schedule, which would have meant putting a compliance requirement at risk. We could try to do both, which would have meant understaffing both and likely shipping neither well. Or we could finish the migration, protect the thing we did not have a choice about, and be honest with you about what that meant for Insights.
We chose the third option. What the rest of this post is about is what that choice means in practice.
Why We Did Not Ship Insights Anyway
Section titled “Why We Did Not Ship Insights Anyway”Here is the part we want to be direct about, because we think it matters more than the explanation above.
Even setting the migration aside, we could not have shipped Insights in its current state and called it done. The core data pipeline works. The underlying data is solid. But the dashboard layer - the filters, the date-range controls, the visualization components, the ability to drill into individual records - is roughly sixty percent complete. The remaining forty percent is not polish. It is core functionality that determines whether the product is actually useful.
We considered shipping what we had under a “beta” label. We considered calling it an early access release. We turned those options over for a week and kept coming back to the same problem: an analytics dashboard that cannot filter by date range or break down data by the dimensions you actually care about is not a beta product. It is a broken product with a beta label on it. Sending you to a broken product while calling it the thing we promised would have been worse than saying what we are saying now.
An in-app analytics dashboard exists to save you time. Its whole value proposition is that you can answer questions about your data inside the product, without pulling data out and doing the work elsewhere. A dashboard that does not do that does not give you a beta version of the value. It gives you no version of the value, with an extra step of logging into a new part of the product to discover the gap.
We have seen what happens when teams ship something that looks like the promised feature but is not. Users explore it, find the gaps, and stop trusting the product’s changelog. Getting that trust back takes longer than the delay would have. We have been on the receiving end of that as users ourselves, and we decided we were not willing to do it to you.
What We Are Shipping Before Q3 Ends
Section titled “What We Are Shipping Before Q3 Ends”We are not going to leave you with nothing.
By the end of September, we will ship a CSV export of the underlying Insights data. This is not Insights. We want to be clear about that so there is no confusion. You will not get a dashboard. You will not get in-product filters or visualizations. What you will get is a structured, well-documented export of the same data that Insights will eventually surface - your event counts, your user activity records, your conversion funnel data - formatted so it can be loaded directly into a spreadsheet or BI tool you already use.
This gives you something real. If you have been waiting for Insights because you have reporting questions you cannot currently answer, the CSV export will let you start answering them now. The format will match the eventual Insights schema, so any analysis you build in a spreadsheet or BI tool today will map cleanly to Insights when it ships. We are treating the export as a compatibility bridge, not a throwaway feature.
What it does not give you is the in-product experience. You will still need to pull the data out, load it somewhere, and do the analysis in a separate tool. We know that is the thing you were trying to avoid by asking for Insights. We know this is a partial answer. We are offering it because it is the honest partial answer - something with actual utility, clearly labeled for what it is, rather than a product that looks complete but delivers nothing when you try to use it.
The export will ship to all accounts before September 30. You will receive a product announcement when it is live, with documentation on the data structure and example queries to get you started quickly.
Where Insights Goes From Here
Section titled “Where Insights Goes From Here”Insights is now a Q1 commitment. That means a ship target in the January-to-March window of next year. We are not putting a specific date on it today because the right thing to do is let the team close out the billing migration, finish Q3 cleanly, and then plan Q4 work with an honest view of capacity. We will share a firmer timeline in October, when we have that view.
What we can tell you about Q4 is that it is budgeted primarily around Insights. The migration is done; it will not bleed into the next quarter. The Insights work that exists - the data pipeline, the backend services, the initial dashboard components - is solid and will carry forward. We are not starting over. We are finishing.
A few things will be different in the Q1 build compared to what we had originally scoped for Q3. Based on the questions we heard most often from customers and from the sales team over the past several months, we are moving the filter and breakdown experience to the top of the priority list. Those capabilities were part of the original release plan but were ranked below the core metrics views. They are now ranked first.
The reason for the change is what we learned from scoping the CSV export. The most common question customers bring to us is “show me this number broken down by this dimension over this time period.” If we ship Insights without that being fast and obvious, we will have a dashboard that technically shows data but does not answer the question people actually have. That is not acceptable. We would rather take the extra weeks to get the filter experience right than ship on an earlier date with a product that disappoints the moment someone tries to do real analysis.
If you would like to be notified when we have a firmer Q1 date, reply to this post and we will add you to the direct update list. The sales team is also tracking Insights as a named priority item and can follow up individually if you would prefer a conversation to an email thread.
What This Actually Costs
Section titled “What This Actually Costs”We want to end here - not with a recap, because you have read the recap above and you do not need it repeated.
What this costs is a quarter. Specifically, it costs the quarter you were counting on. If you made a commitment to your leadership or your customers based on what we told you about Insights, you now have to go explain a change you did not make. That is a real cost, and we are not going to minimize it by pivoting immediately to how excited we are about Q1.
We made you a promise. The right move when you break a promise is not to immediately make a new, shinier promise and hope the first one gets forgotten. The right move is to account for the one you broke, explain what happened, and make the next commitment in a way that gives you some reason to believe it.
What we hope this does not cost is your confidence that we will tell you the truth when things change. We cannot unsay what we said about Q3. We cannot give you the dashboard before it is ready. What we can do is be the kind of team that tells you what happened when something goes sideways, explains the tradeoff instead of hiding it, and ships the bridge instead of pretending nothing changed.
The CSV export is real and ships before the end of this quarter. The Q1 commitment is serious and carries the full weight of what we still owe you. And this post is us saying: we know what we owe you, and we intend to spend the rest of this year paying it.
Onboarding a New Engineer: Start at the End
Section titled “Onboarding a New Engineer: Start at the End”Most onboarding plans start where they should end. They begin with access requests and tool installations, work through codebase walkthroughs and architecture diagrams, stack meeting introductions on top of process explanations, and arrive somewhere in week two at the idea that maybe the new engineer should try something. By then, the person sitting across from you has been saturated with information and starved of action, and they are still not sure whether they are a visitor or a resident.
That order is backward. The moment that tells a new engineer whether they belong is not the welcome meeting and not the first day their laptop works. It is the first time they ship something real - something that goes through the team’s actual process, touches code that matters, and lands in production. Everything else in the two weeks is infrastructure for that moment.
So when Priya showed up Monday morning, the question I asked myself first was not “what does she need to know?” It was “what does she need to ship by Friday of week two, and what would have to be true for that to happen?” That reversal changes almost every decision you make.
The First Week Is Not About Productivity
Section titled “The First Week Is Not About Productivity”If you are honest about what the first week is for, it is not productivity. A new engineer on a team that ships daily and runs an on-call rotation is not going to contribute meaningfully to either of those things in her first five days. She does not know the codebase well enough to review a pull request with confidence. She does not know the deployment process well enough to trust herself in it. She does not know which services talk to each other, which corners are clean and which are minefields, or where to look when something breaks.
That is not a failure of hiring - that is the nature of codebases and teams. They accumulate context. A new person starts with none of it, and the first week is about reducing the ambient anxiety of having none of it enough that she can actually pay attention.
Access and tooling matter here, but not for the reason most onboarding checklists frame them. The checklist framing is operational: she needs credentials to do her job. The human framing is more important: a person who spends her first two days unable to log in, waiting on access tickets, staring at a machine that will not connect to the build system - that person has spent two days being told, by friction, that the team was not quite ready for them. Even if no one meant it that way.
Get the access sorted before Monday. Not “create the tickets before Monday” - actually get it done. Repository access, the deployment pipeline, the ticket tracker, the chat tool, the documentation system, the on-call tooling. If there is a staging environment she should be able to push to, confirm she can push to it. This is a two-hour project done the Friday before she starts. It signals that her arrival was anticipated and that the team’s operational machinery is already hers.
The codebase orientation is not a lecture. Walk her through one service - not all of them, one of them - in enough detail that she can follow a change from local development to production. Pick the service where her first change will live. The goal is not comprehensive understanding. The goal is “I know where to look when I need to understand something.” That is enough for week one. Comprehensive understanding is a six-month project.
One more thing: put on-call on the calendar for her as a shadow, not a participant, starting in week two. She should see what it looks like before she is ever on it. But do not make week one about on-call preparation. The rotation exists to support the service; the first week exists to support her.
Finding the Right First Change
Section titled “Finding the Right First Change”The first real change is the critical design decision in any onboarding plan, and most people make it wrong in one of two directions. Either they pick something so small it feels like a test - fix this typo, update this config value, add this comment - which tells the new engineer that the team does not trust her with anything that matters. Or they pick something too large, something that requires understanding three services and a month of history, and she spends two weeks making progress she cannot quite see toward a change that does not quite land by the deadline.
The right first change is genuinely small and genuinely real. Small means: one service, one behavior, well-understood scope, reviewable in a single session. Real means: it matters to the team that this gets done, it touches the production codebase, and when it ships, something is better than it was.
Bug fixes that are clearly scoped work well. Small feature additions to an internal tool work well. Improvements to a test suite work well - this is underrated, because tests live at the edges of the codebase and teach a new engineer a great deal about how the team thinks about correctness. Documentation fixes in the codebase itself work less well, because they feel - and often are - purely accommodating to the new person rather than useful to the team.
Pair on the first change. This does not mean sitting next to her while she types. It means: you have already looked at the area of the codebase the change touches, you know where the tricky parts are, you are available when she hits them, and you have agreed that you will review her pull request with the attention of someone who cares about the outcome rather than just the onboarding milestone. The pairing makes the change real. It is the difference between doing a practice run in a simulator and flying with someone who will catch you if you reach for the wrong lever.
The review conversation is part of the onboarding. When you review her first pull request, you are not just checking the code. You are modeling how the team thinks about changes. What do you comment on? What do you let go? What question do you ask instead of stating the answer? This is the first time she gets to see the team’s taste expressed directly toward her work, and it either feels like engagement or it feels like judgment. How you write your review comments matters.
The Velocity Trap
Section titled “The Velocity Trap”This is the part that teams with daily shipping and on-call rotations get wrong most often, including teams that otherwise onboard thoughtfully.
A team that ships every day has a visible, ambient pace. The ticket tracker churns. The deployment log rolls. People talk in the chat tool about changes that went out that morning, incidents that happened last night, decisions that were made in a meeting she was not part of. She can see all of this. On day three, Priya can see that her teammates have shipped several things and she has shipped nothing, and the part of her brain that tracks social safety starts doing math she did not ask it to do.
You do not manage this by telling her not to worry about it. You manage it by making her work visible. Give her a short list - two or three things - that she is explicitly working on this week. Put it somewhere she can check items off. The list is not about productivity management. It is about giving her concrete evidence that she is making progress in a place where progress is otherwise hard to see.
Similarly, the on-call rotation can feel like a permanent weight hanging over a new engineer. She does not know the services well enough to debug an incident confidently. She knows she will be on call someday, and she does not know when, and she does not know if she will be good at it. The antidote is specificity. Tell her: you are shadowing the rotation for the next two weeks, you will have a primary partner for your first several stints after that, and there is a documented playbook for the most common alerts. Then show her the playbook. Let her read it before she needs it.
The broader point is that arriving into a high-velocity environment feels like arriving into a river. The current is moving and you are standing in it. The way you make that feel safe is not by slowing the river. It is by giving the new person a handhold - something to grip while they find their footing. Access sorted before day one, a clear first task, visible progress, and explicit on-call scaffolding are the handholds. They do not slow the team down. They are just the architecture of belonging in a fast environment.
Who Owns What, and Why She Needs to Know
Section titled “Who Owns What, and Why She Needs to Know”Onboarding guides often treat ownership maps as operational logistics. She needs to know who owns a given service because if something breaks in that service she needs to know who to call. That is true, but it is not the most important reason to make ownership legible early.
The more important reason is that a person who understands ownership understands the team’s structure of intention. She can see who cares about what, where the centers of gravity are, which areas are being actively developed versus maintained at steady state. That map tells her where she can have opinions that will be heard, where to bring her own ideas, and whose perspective to seek before proposing a change in a given area.
This matters for belonging in a way that feels abstract until it is not. A new engineer who does not know the ownership map tends to either avoid proposing things - because she does not know if it is her place - or propose things without context - because she does not know whose territory she is in. Both patterns create friction that can look like the person does not fit, when what is actually true is that the team did not make the map available to her.
Spend thirty minutes in the second week walking through ownership with her. Not the org chart - the actual codebase ownership, including the parts that are genuinely ambiguous or contested. Ambiguity is not a defect to hide from a new person. It is context. She will learn more about how the team actually works from one honestly ambiguous ownership conversation than from a week of clean documentation.
And then ask her a question. Not a test - a real question. Something like: “Which of the services we have talked about feels most interesting to you and why?” This signals that she is not just being onboarded into a static structure. She has opinions worth having. The team is curious about them.
What Happens at the Merge
Section titled “What Happens at the Merge”The end of week two, Priya merges her first pull request. The CI passes, the deployment runs, and something in production is different because she touched it. That moment is quick - a few minutes in a workday full of other things. She probably feels a mix of relief and something harder to name.
What happened in that moment is what you were building toward for two weeks. Not the change itself - the change is small. What happened is that the process became hers. She knows how to get a change into the repository. She knows who looks at it. She knows what the deployment looks like. She knows that when something breaks she has a path to getting help. She has done the thing the team does, and she has done it for real.
That is the difference between functioning and belonging. Belonging is not a feeling you produce by being warm enough in the welcome meeting, though warmth matters. It is a feeling that accumulates from evidence - evidence that the work is yours to do, that the team is yours to be part of, that your presence here was anticipated and is wanted. The two weeks of setup, the careful first task, the pairing, the ownership conversation, the on-call scaffolding - all of it is manufacturing that evidence.
By Friday of week two, Priya should not feel like she has finished onboarding. She should feel like she has started.
She Vouched for Me Before I Could Vouch for Myself
Section titled “She Vouched for Me Before I Could Vouch for Myself”Three months ago I put someone I manage forward to lead a project she had told me she wasn’t sure she was ready for. I told her she was. She wasn’t entirely. The next six weeks were uncomfortable to watch: missed signals, overcorrections, a presentation that landed flat, a stakeholder relationship that required repair. I sat through a few of those meetings and kept my mouth shut when I could see exactly what needed to be said.
Somewhere around week four, I realized I was doing something I had seen done for me. I just hadn’t named it until that moment.
A decade ago, a woman named Dana did the same thing for me. I’ve thought about her often since - the way you think about a particular kind of person who doesn’t announce herself as a mentor but simply acts, and leaves you to sort out what happened years later. I’ve been meaning to say something to her for a long time. This is my attempt to actually say it.
What She Put on the Line
Section titled “What She Put on the Line”I was two years into my career when I first landed in Dana’s orbit. She managed a different team but had been asked to advise on a cross-divisional initiative - the kind of project that gets assembled when something is broken enough that no single department can own the fix. The goal was to redesign how work moved between two teams that had been quietly failing to coordinate for years. It was politically careful territory, and the initiative mattered to people who had real authority.
At some point early in the project, there was a question of who would lead the working group. I don’t know what conversations happened before Dana came to me. I only know that she did come to me, in a brief meeting I remember as feeling slightly surreal, and she said something like: I’ve been watching how you think about problems. I’d like to put your name forward for this. It’s going to be harder than you expect.
I asked if she thought I was ready. She said: probably not yet, but that’s not quite the right question.
I’ve turned that line over many times in the decade since. At the time I filed it away as reassuring noise - the kind of thing a generous person says to settle your nerves. It took years to understand she meant it precisely, not comfortingly. The question of readiness is almost always answered on the other side of the experience, not before it. Asking whether you are ready before you’ve done the thing is asking a question that has no honest answer. You find out by going.
What she put on the line by nominating me was her own judgment. When a senior person vouches for someone junior, they’re not simply offering an opportunity. They’re attaching their reputation to a bet. If I collapsed, that would reflect on Dana - on her ability to read people, on her willingness to stake organizational credibility on someone unproven. She knew this. She did it anyway.
What Staying Close Actually Costs
Section titled “What Staying Close Actually Costs”Here is the part I got wrong in my memory for a long time.
For years, when I told the story of what Dana did for me, I told it as: she handed me an opportunity and stepped back. That made her generous and me resourceful. It’s a clean story. It’s also not quite accurate.
Dana didn’t disappear after she put my name forward. She stayed in the periphery - not in most of the rooms, but accessible. In the weeks when the project was hard, and there were several of those, she would check in briefly. Not to tell me what to do. To ask me what I was thinking. There is a distinction there that I used to flatten but don’t anymore.
Telling someone what to do is efficient. Asking them what they’re thinking is slow and often uncomfortable, because sometimes what they’re thinking is confused or incomplete, and you have to sit with that rather than correct it. You have to hold back the reflex to step in and say: here, let me show you. You have to wait for them to find the thread themselves, knowing that it will take longer than if you had just handed it to them.
I know what that costs now because I’ve been on the other side of it. When the person I manage was struggling in week four of her project, I knew exactly what the stakeholder needed and exactly how to give it to her. Saying nothing, asking questions instead, leaving the room and letting her work through it - that was not passive. It was active restraint, and it was harder than fixing it myself would have been.
Dana did that for me across an entire project. Week after week, she resisted the efficient choice. That is not generosity in any soft sense. It is a specific kind of discipline - patient and costly and invisible from the outside. You are choosing the slower path because the slower path is what actually develops the other person. The shortcut would have helped me in the meeting. The longer way helped me in every meeting after that.
I don’t know if she thought of it that way. She never said. But the effect was the same regardless.
What It Made Possible
Section titled “What It Made Possible”The project didn’t go perfectly. I could name the specific failures: a scoping decision early on that created rework later, a communication gap with one team that I let sit too long before addressing, a moment in a review meeting where I let uncertainty show in a way that unsettled people who needed confidence from me. There were hard weeks, and I carried the weight of them in ways that made me less easy to be around outside of work.
But I got through it. And what I walked away with was not only the skills the project taught me - how to run a working group under pressure, how to manage upward when the stakes are real, how to repair a relationship I had frayed. I walked away with something harder to name.
When someone who knows how to evaluate people bets on you before you have evidence to offer, it changes what you think you are capable of. It gives you a reference point that didn’t exist before. You know that someone with good judgment looked at you - unfinished, uncertain, not yet proven - and decided you were worth the risk. That knowledge sits differently than any credential or performance review. It doesn’t tell you that you’re good. It tells you that you’re possible.
That is an asset with a long half-life. I have drawn on it in moments when I wasn’t sure I belonged in a room, when a harder assignment came along and I had to decide whether to reach for it. Each time, somewhere in the calculation, there was Dana’s original bet.
And then there is this: when you’ve been carried that way, you eventually do it for someone else. Not because you decide to follow a principle. Because you know what the shape of the thing looks like. You’ve felt it from the inside. When the person I manage came to me uncertain about whether she was ready, something in me recognized the moment and knew, without fully reasoning it out, what the right response was. Don’t take over. Stay close. Ask questions. Let her find it.
I learned that somewhere. I learned it from Dana.
She ran the project close-out meeting last week. There was a difficult moment about two-thirds through, when a stakeholder pushed back on a recommendation more sharply than the agenda had suggested, and she handled it with a self-possession she hadn’t had in week two. She didn’t deflect or defer. She addressed the concern directly, acknowledged what was genuinely uncertain, and moved on. I was watching from a corner of the room. She didn’t look at me for help.
She didn’t need to.
Dana, I don’t know where your career has taken you in the past ten years. People scatter, and staying in touch is one of those things that most of us intend and fewer of us do. But I want to say this while I can say it clearly: the project you handed me has compounded. Not only in what I learned to do, but in what I learned to see. I see the people who work with me as unfinished in the best possible way - not lacking, but becoming. I know that the most useful thing I can often do is hold back, ask questions, and let them find their footing on ground that is genuinely theirs to claim.
You gave me that. I’m passing it on.
The Day That Does Nothing Makes Everything Else Work
Section titled “The Day That Does Nothing Makes Everything Else Work”I used to think the productive week was the one without gaps. Six and a half days of output, or seven if the project demanded it - that was the math I had internalized. Rest was what happened when you ran out of energy, not something you planned. Planned rest felt like planning to fall behind.
I know I am not alone in this. The pressure does not require a demanding boss or a startup culture; it can come entirely from the inside. The to-do list does not stop on Saturday. The chat tool still shows unread messages. The sense that you are behind, or could be, does not observe a calendar. So when I first tried to keep a full day of rest each week - one day of genuinely putting down work, stepping away from notifications, and refusing to “just check one more thing” - it did not feel peaceful. It felt like agitation.
What I want to write about here is not a productivity hack. It is not a rebranded efficiency technique that turns rest into a strategy for doing more work later. I want to write honestly about what a discipline of real rest costs, what it seems to take away, what it eventually returns, and what it asks of someone who has spent years measuring their days by what they produced.
Why the First Few Hours Are the Hardest
Section titled “Why the First Few Hours Are the Hardest”The first thing I noticed, when I started trying to take one full day off per week, was how quickly a vague anxiety surfaced. This was not dread of anything specific. Nothing was on fire. No deadline was slipping. It was more like the absence of forward motion itself felt like a kind of falling.
I have since talked to enough people to know this is common. When your sense of self is bound up with your output - when the running mental list is how you know you are on top of things - stillness does not feel like rest. It feels like standing very close to the edge of something. The internal monologue fills the space immediately: I should use this time to think through that problem. I could draft the outline now and not call it work. What if I just looked at my inbox and did not reply to anything?
Every one of those thoughts was a negotiation, and I recognized them because I had lost the negotiation before. I would give myself permission to “just look” and an hour later I would be deep in a thread, solving a real problem, and telling myself it had barely counted. The day would dissolve. And then, without a day of genuine rest, the following week would arrive with all the same weight as the week before - because nothing had been set down.
The trouble with this pattern is that it reinforces itself. You do not rest, so you carry the accumulated tension of the previous week into the next one. The next week feels heavier. You feel more behind. The case for skipping rest becomes stronger because there is genuinely more to catch up on. I have watched this spiral in myself over multiple seasons, and the mechanism is not subtle once you have seen it.
What I Gave Up (and What I Thought I Was Giving Up)
Section titled “What I Gave Up (and What I Thought I Was Giving Up)”When I started taking a full day off seriously - not perfectly, but with real intent - the first loss I felt was time. A seventh of the week is significant. If you are in a season of building something, or managing a heavy load, or trying to finish a project before a deadline, one day out of seven looks like exactly the deficit it sounds like.
The second thing I thought I would lose was momentum. There is a kind of cognitive continuity in staying close to a problem - you hold the threads in working memory, you pick back up faster, you do not spend Monday morning reconstructing what you were thinking the previous Friday. I was genuinely worried that a full day away would cost me that continuity, that I would show up to the following week disoriented.
Neither of these fears turned out to be false, exactly. They just turned out to be incomplete.
Yes, a day of rest is a day not spent producing. If your measure of a week is hours of direct output, you will not hit the same number in six days that you would have hit in seven. That is true, and I do not want to paper over it with a claim that you will somehow output more by doing less. That is not what I found.
What I found was that the quality of what I did on the other six days changed. Not immediately - the first few weeks of trying this, I was mostly just anxious and fidgety on the rest day, and showed up to Monday tired from the effort of not working. But slowly, something shifted. The rest day started to do something I had not expected.
The Thing Rest Does That You Cannot Do While Working
Section titled “The Thing Rest Does That You Cannot Do While Working”Here is the best way I can describe it: when you never stop, you never surface.
Working is immersive by design. Good focused work requires not stepping back. You are inside the problem. That is where the progress happens. But there is a different kind of seeing that only happens when you are outside the problem - when you have physically and mentally left it alone long enough for your perspective to reset. The decisions that looked obvious from inside the work look different from outside it. The thing you were worried about all week sometimes looks smaller. The thing you were ignoring sometimes looks much larger.
I started noticing this in a concrete way. Monday mornings, on the weeks when I had genuinely rested on Sunday, felt different. Not energized in a caffeinated sense, but clearer. The week’s priorities seemed more obvious. I knew, with more confidence, which things mattered and which things I had been treating as urgent because they were loud rather than because they were important.
This is not magic. It is what any experienced craftsperson or designer would tell you happens when you sleep on a problem: the background processing that happens when you are not forcing it. But the same principle applies to a week, not just an overnight. You need enough distance from the work to see the work. A single evening does not get you there. The day has to be long enough, and different enough, that it actually creates separation.
The “different enough” part matters more than I expected. Early on, I tried resting in ways that were still adjacent to work - reading industry material, listening to podcasts about strategy, thinking through problems on walks. These felt restful because they were not directly productive. But they were not actually resting my work-mind. The themes were still running. What finally started working for me was a different kind of doing: unhurried time with people I cared about, physical activity without an outcome goal, cooking something slowly, reading fiction. Things that required attention but not the kind of attention that depletes.
The Discipline That Makes It Real
Section titled “The Discipline That Makes It Real”None of this is automatic. I want to be clear about that, because when people write about rest it can sound like they discovered a natural gear they were missing, something that kicked in smoothly once they gave themselves permission. That has not been my experience.
Taking a day of rest every week is a practice, which means it requires intention, and intention requires decision, and decision requires revisiting regularly because the pressure to not take the day never fully goes away. There is always a week that seems like a bad week to rest. There is always a plausible argument for making an exception. The discipline is less about remembering to rest and more about refusing the exception-making.
I have found it helps to make the day visible. Not to perform rest for anyone - I am not posting about it or explaining myself to colleagues - but to have a clear threshold for what the day is and what it is not. The phone goes on a setting where only actual emergencies can reach me. I do not open my work tools. I do not read work-related material, even the kind that feels like leisure. The threshold is not a judgment about what counts as real work; it is a practical demarcation that I set once and do not renegotiate in the moment, because negotiating in the moment is how the day disappears.
This sounds rigidly structured for something called rest, and I have thought about that. But I think the structure is actually what makes the rest real. Without it, the day becomes porous - a collection of small exceptions that individually feel harmless but together fill the space where rest was supposed to go. The structure is not there to police me. It is there to remove the decision from the day itself, so I am not spending energy defending the rest while I am supposed to be resting.
What It Asks of You
Section titled “What It Asks of You”The deepest thing a discipline of rest asks of a person who measures days by output is a willingness to sit with the discomfort that your value is not equivalent to your productivity. That sounds like a piece of self-help advice, and I am somewhat suspicious of it even as I write it. But I have found it to be practically true in a way I did not expect.
When I work through rest days, I feel better immediately - because I am doing something, making progress, moving a number in the right direction. When I take the day off, I sometimes feel worse in the moment - because I am not moving anything, and the gap between where I am and where I want to be does not close. Choosing the rest day anyway is a small act of trusting that the longer arc matters more than the day’s scorecard.
That trust builds slowly. The first few times you take a full rest day and then show up to the following week, and the week is not worse than if you had worked - and in fact something about it is easier - that is evidence. You start to build a different kind of confidence: not that you produced enough, but that you are oriented well. These feel like different things. The first is a daily calculation. The second is a quality that accumulates.
I am not a different person because I keep a day of rest each week. I still feel the pull to check things, to add one more hour, to negotiate myself out of the day when the workload is heavy. But I have a more honest relationship with what that pull is, and what it costs to give in to it. The day of rest is not a cure for anything. It is a practice - something you return to, something you decide again, something you lose and find again over the course of a life.
What the Day Returns
Section titled “What the Day Returns”A full day set apart each week will not give you back a seventh of your output. I want to say that plainly because I think it is important not to sell this on false terms. The arithmetic does not work that way.
What it does give you is harder to measure and more important. It gives you a recurring point of return. A place in the week where you come off the treadmill long enough to ask whether you are running in the right direction. A container for the kind of recovery that enables the other six days rather than merely extending them.
It also gives you something I did not expect to value as much as I do: a kind of steadiness. Not the steadiness of never being stressed, but the steadiness of having a rhythm that does not depend on the week going well. The rest day happens whether the project is on track or not, whether I cleared the backlog or not, whether I feel like I earned it or not. That consistency turns out to matter. It is a structure that holds the week rather than a reward that waits at the end of it.
The week that has a real rest day in it is a different week than the one that does not. I did not believe this when I first tried it, and I am not sure anything I write here will be more persuasive than the experience of trying it yourself for long enough to get past the agitation of the first few weeks. But I have come to believe it, and the belief has changed how I work - not by making me more efficient within the hours I have, but by reordering what those hours are for.
One day is not a vacation. It is not a reward. It is not a productivity strategy. It is a practice of returning to yourself before you have fully lost track of where you are.
That turns out to be enough.
The Person Who Stayed: What Twenty-Six Years Without a Promotion Actually Builds
Section titled “The Person Who Stayed: What Twenty-Six Years Without a Promotion Actually Builds”There is a question that gets asked at every retirement party, in some form or another: “How does it feel to finally be done?” It is a strange question when you hold it up to the light. It assumes the career was something to be endured - a long tunnel with a fixed endpoint - and that the endpoint is the point. For most careers, the frame is at least partially wrong. For a career like Howard Pell’s, it misses almost everything.
Howard joined Meridian Group in February 1998. The company was smaller then, noisier, occupying only the fourth floor of what is now a twelve-floor operation. He came in as an Operational Services coordinator and, over twenty-six years, never left that department. He took on more responsibility over time, his title changed once, and he became - by gradual and unannounced accumulation - the person the whole organization depended on in ways that were impossible to diagram. He was not passed over for advancement. He did not want advancement in the way advancement usually works. He wanted to know the work deeply. And he did.
This post is not a resume of what Howard accomplished, partly because he would hate that, and partly because the list would be misleading anyway. The most important things Howard did at Meridian do not appear in any quarterly report. They live in the habits of the people he quietly shaped, in the decisions that got made correctly because someone remembered why a wrong version had been tried before, and in the crises that did not become catastrophes because one person in the room had already seen something close. What his retirement actually marks is not the end of a career. It is the departure of a kind of knowledge and presence that most organizations never think to name until it is gone.
What Institutional Memory Means When It Actually Walks Out
Section titled “What Institutional Memory Means When It Actually Walks Out”We talk about institutional memory as if it were a filing system - something that could, in principle, be captured in documentation, archived properly, and handed off. Howard would be the first to say that documentation matters. He maintained meticulous records. But the thing he carried that no document could hold was something closer to a mental map of the organization’s own reasoning: not what had been decided, but why, and what had been tried before the decision, and what had gone wrong in the attempt.
He kept a composition notebook for the first several years, a habit he once described as “keeping score on the organization’s arguments with itself.” By the time notebooks felt insufficient, the habit had moved into his head. He knew that the current vendor approval process was shaped by a specific failed procurement in 2007, and that the failed procurement was itself a correction to an earlier approach that had created different problems. When a new operations lead proposed revisiting the original approach in 2019 because it looked cleaner on paper, Howard was the person who sat down with her and walked through the full history - not to shut the idea down, but to make sure she was proposing what she actually meant to propose, with eyes open to what had been tried before.
That is not a thing you can archive. It is a form of knowledge that requires continuity - someone who was present for the reasoning, not just the outcome. It requires, specifically, a person who stayed.
Organizations shed this kind of knowledge constantly and mostly without noticing. Someone leaves, and the organization notes the open role. A few months later, the team makes a decision that would have been made differently with the full history available, and nobody quite knows why the outcome feels slightly off. The connection between the departure and the error is usually too indirect and too delayed to be visible. Howard understood this clearly. It was one of the reasons he documented as carefully as he did - he was always preparing for a version of Meridian that would not have him in it.
His leaving will leave gaps that documentation cannot fill. The team is aware of this. The question of how to manage it - how to build the kind of continuity that Howard represented almost accidentally - is one the organization will be working on for some time.
The Invisible Curriculum
Section titled “The Invisible Curriculum”Howard mentored people. He would object to the word, because he never sat anyone down and announced that he was doing it. But the number of people at Meridian who can trace a significant professional development to a conversation with Howard is not a small number.
Delia Okafor joined Operational Services seven years ago, fresh out of a graduate program, carrying the kind of systematic confidence that graduate programs build: she knew the frameworks, she could apply the models, she was ready to optimize things. What she was not ready for was the particular texture of how things actually get done in a large organization - the informal agreements that structure formal processes, the people who need to be in the room before a thing can move forward, the difference between a decision that is made and a decision that will stick.
Howard did not give her a lecture on organizational dynamics. He asked her questions. When she brought him a plan, he would say something like “Who else has seen this?” or “What does Facilities think about this part?” - questions that pointed her toward the thing she had not yet thought to look for, without telling her what she would find. She describes the experience now as feeling like she was being handed a map with no labels that became legible as she explored it. Within two years, she was doing the same thing with newer hires, asking the same kind of quiet, directional questions. The curriculum was self-propagating. Howard had not planned that, but it did not surprise him.
Marcus Threadgill has a different version of the story. He came to Howard not as a mentee but as someone who was about to leave the company. He was frustrated, certain that his skills were not being used well, preparing to take a job elsewhere. He mentioned it to Howard in passing, not really expecting much. Howard listened for a while and then asked him something unexpected: “What would have to be true for this to be the right place?” It was the kind of question that reframes a situation instead of arguing with it. Marcus stayed - not because Howard talked him into it, but because the question made him realize he had not clearly identified what he actually wanted. He has been at Meridian for six years since that conversation. He is currently leading a team.
Priya Sundaram would say she did not work with Howard at all. They were in different departments, overlapping only occasionally. But she remembers asking him at a company event how he thought about managing competing priorities across projects that all felt urgent. He gave her an answer she still repeats: “Most of the urgency is borrowed. Find out who lent it and whether they actually want it back.” She had been overthinking the problem in frameworks. He reduced it to a human question in one sentence. That is the kind of pedagogy that does not leave a trace in any training system.
The invisible curriculum Howard ran was distributed, informal, and utterly unplanned. It ran on proximity and attention - his habit of noticing when someone was stuck and his willingness to ask rather than tell. It produced nothing that appears in the org chart. It produced people.
When Things Go Wrong and One Person in the Room Has Seen It Before
Section titled “When Things Go Wrong and One Person in the Room Has Seen It Before”In early 2014, a data migration project that had been running for six months hit a failure that nobody had anticipated and that cascaded quickly into a service outage affecting most of the company’s eastern operations. The team working on it was competent and experienced, and they were completely lost. The failure mode was not in the migration plan - it was in an interface between two legacy systems that had been documented incorrectly years earlier and that nobody currently on the team had worked with directly.
Howard had worked with those systems. He had not been part of the migration project. He walked into the room because someone had the presence of mind to call him, and he spent four hours helping the team understand what they were actually looking at and what their options were. The outage was resolved without data loss. After the fact, the project lead said that Howard had saved the project not by knowing the fix but by knowing the territory - he could read the failure because he had context for what normal looked like in that system, and he could see immediately what was anomalous.
This is a specific kind of value that only time produces. You cannot hire for it. You cannot build it through training. It accumulates in a person who stays in close contact with a system long enough to understand not just how it behaves in ordinary conditions but how it fails - what the warning signs look like, what the typical patterns of cascade are, where the fragile points are that the documentation does not mention because the documentation was written before the fragility appeared.
Howard was present for several failures of that kind over twenty-six years. Each one added to his map. That map is not transferable. What transfers is the habit he modeled: the importance of maintaining deep familiarity with the systems you are responsible for, even when the systems are stable, even when nothing appears to require your attention. Stability is when you build the knowledge you will need when stability ends. Howard knew this in his bones. It was, perhaps, the deepest thing he tried to pass on.
What the Org Chart Does Not Show
Section titled “What the Org Chart Does Not Show”When Howard leaves, the Operational Services department will continue operating. The role will be filled. The work will get done. Anyone watching from outside would see a smooth transition. An org chart drawn the week after his retirement will look essentially like the one drawn the week before.
What it will not show is the network of informal knowledge, connection, and accountability that he held in place. It will not show the new hire who will not get the quiet directional question that would have saved her six months of confusion. It will not show the next data migration project, running into something unexpected, with nobody in the room who has seen that particular failure mode before. It will not show the conversation that does not happen because the person who would have had it is gone.
Organizations rarely notice these absences directly. They show up sideways - in slower recoveries, in decisions that miss a dimension, in the gradual drift of institutional reasoning away from its own history. By the time the absence is visible, it has already been doing its work for years.
What Howard gave Meridian over twenty-six years was not a set of completed projects or a list of accomplishments. It was the ongoing work of staying - of accumulating, translating, and quietly distributing the kind of knowledge that keeps an organization in contact with itself. He did it without a mandate, without a title that named it, and without much apparent interest in making it visible.
That is, in the end, the specific argument his departure makes. There is a kind of career that does not look like a career from the outside - it has no ladder, no ascending titles, no signal of ambition being rewarded. It looks like staying. What it is, when it is done with Howard’s particular combination of attention and care, is leadership exercised at depth rather than altitude. The organization is less because he is leaving. The people he shaped are better because he was here.
The room where he would have asked the right question will be slightly quieter from now on. That quiet is what a retirement actually marks, when the career was a real one - not the end of the tunnel, but the absence of the person who knew where all the passages went.
Fourteen Months Under the Ice
Section titled “Fourteen Months Under the Ice”What It Actually Cost to Rebuild Checkout While the Store Stayed Open
There is a category of engineering work that is almost impossible to see from the outside. The systems are running. The customers are checking out. Nothing looks broken, and nothing looks fixed, because nothing looks changed at all - except that it is. Somewhere underneath the visible surface, a team has been rebuilding the foundation while the building stayed open, and the measure of how well they did it is precisely the absence of anything dramatic to point to.
That is what the checkout team at Marlowe Commerce spent fourteen months doing.
On June 12th, they flipped the last routing flag. The old checkout flow - a system that had accumulated more workarounds than original lines over six years - was retired. The new system handled its first full peak-load day without a single escalation. Cart-abandonment rates dropped to a range the business had not seen since its early years. And the team, who had been carrying two production systems simultaneously for most of a year, finally got to carry just one. This post is an attempt to give that work its due - to name what it actually cost and what it took, because this kind of project does not speak for itself.
The Problem Was Not What It Looked Like
Section titled “The Problem Was Not What It Looked Like”When Carmen Orozco joined the data team in early 2024, one of her first assignments was to dig into the cart-abandonment numbers. The business knew the rate was high. It had been high for two years. The standard explanations had already been explored: friction in the form fields, slow page loads, an unclear total-cost display before the final confirmation step.
Carmen’s analysis agreed with those findings - but it also found something underneath them. The abandonment was not randomly distributed across users. It was heavily concentrated in sessions where a user encountered a timeout error, a state mismatch between the cart and the payment step, or a silent failure that showed no error at all but simply failed to commit the transaction. These were not user-experience problems. They were system-integrity problems. The checkout flow had been extended so many times, by so many hands, that it could no longer guarantee its own state.
This finding changed the conversation. Patching the user interface - adding clearer error messages, reducing form fields, speeding up the page - would address visible friction. But it would not fix the silent failures, because the silent failures were not about friction. They were the result of a system that no longer had clean contracts between its own pieces. You could not make that system reliable without rebuilding it.
Priya Sundaram, who led engineering on the project, later described the decision this way: the question was not whether to rebuild - the question was whether to admit that the rebuild was the cheaper path. It felt more expensive. It felt like the kind of decision that requires explaining every quarter for the next year. But the alternative was to keep patching a system that had become structurally unpatchable. The decision was made in April 2024. The project got a name - internally, the team called it Keel - and a target: have a new system in production before the following peak season.
What Running Two Systems Actually Costs
Section titled “What Running Two Systems Actually Costs”The word “migration” undersells what Keel required. Migrations move data or traffic from one place to another. What the checkout team built was a fully functional parallel system that had to be correct and current every day, while the old system remained authoritative for every transaction that had not been explicitly moved over.
For the first three months, this was largely invisible to the rest of the company. The team was building. They were not yet maintaining two production systems; they were maintaining one and building a second. But as Keel moved into integration testing and began handling small percentages of real traffic, the maintenance burden began to double. Every incident in the old system had to be triaged against the new one. Every schema change on the old system had to be evaluated for compatibility with the new one. Every edge case discovered in production had to be reproduced, understood, and handled in both codebases.
Dev Matsuda, who owned the backend integration layer, later estimated that for a six-month stretch, roughly a third of his team’s capacity was consumed by this synchronization work - work that produced no visible features, no shipped improvements, no changelog entries. It was the kind of labor that does not appear on a roadmap and does not earn a slide in the all-hands deck.
And then came the near-misses.
The first happened in October 2024. A routine change to the payment-provider integration introduced a subtle race condition in the new system’s state handling. It was caught in load testing - barely. The root cause took four days to isolate. Had it reached production, it would have manifested as exactly the kind of silent failure the project was built to eliminate: transactions that appeared to succeed to the customer but were not actually committed. The team fixed it, but the discovery was sobering. The new system was not yet safe enough to ship.
The second near-miss was quieter and, in some ways, more expensive. In February 2025, a miscommunication between the data team and the infrastructure team created a window where both systems were writing to the same downstream table during a data-sync event. Nothing broke visibly. But for roughly eighteen hours, the reconciliation data that the business depended on for financial close was inconsistent. Tobias Wren, who led infrastructure, caught the discrepancy before it propagated further. Fixing it required four days of careful data archaeology and a late night that nobody has put on a slide yet. These near-misses did not make the project leaderboard. They are the kind of event that gets handled, gets documented internally, and then disappears from the visible record of a project. But they shaped everything that came next.
The Slips
Section titled “The Slips”The original launch target was February 2025. The team had reasonable confidence in December that they would hit it.
They did not hit it.
The first slip was a direct consequence of the second near-miss. The data-sync issue, once fully understood, revealed a broader class of consistency risk that had not been adequately tested. Rushing to the February deadline would have meant launching a system with a known gap in its consistency guarantees. Priya made the call to slip to April. The conversation with stakeholders was not easy. The project had already been running for ten months. The business was watching the cart-abandonment numbers and asking when the investment would pay off.
The April target held until it didn’t. Three weeks before the planned launch, load testing under simulated peak conditions revealed performance degradation in a specific path: bulk-order processing, which accounted for a small fraction of transactions but a significant share of revenue. The path had been tested, but not under the combination of conditions that peak season would produce. The team needed more time.
Priya slipped it again, to June 12th.
The second slip was harder to communicate than the first. By April, stakeholders were not angry - they were beginning to wonder whether the team knew what they were doing. The project had been running for over a year. It had slipped twice. The old system was still running. What was taking so long?
Annika Larsen, who had been managing the stakeholder relationship throughout, later said that the hardest part of the second slip was not the conversation itself - it was the two weeks before it, when the team knew they needed to slip but had not yet made the call. “Everyone was carrying the decision,” she said. “You can feel it when a team is waiting for permission to do the right thing.”
The call came from Priya, clearly and without hedging: they would not ship until the bulk-order path was solid. The June date was realistic. The April date was not. That distinction - between a date that can be defended and a date that feels defensible - is one of the harder things a technical leader has to hold. Priya held it twice.
The Night It Held
Section titled “The Night It Held”June 12th was a Thursday. The team began the final rollout at 6 AM, routing ten percent of traffic to the new system. By noon, they were at fifty percent. By 3 PM, they were at one hundred.
The load tests had predicted what would happen. The load tests were right. Traffic routed cleanly. The silent failures did not appear. The performance metrics stayed inside the bounds the team had spent months establishing. Cart-abandonment in the first twelve hours of full traffic was tracking at the level Carmen’s models had projected.
At 7 PM, the team stood down from active monitoring. Not because the monitoring stopped - the monitoring never stops - but because the moment had passed where active intervention was likely to be required. Tobias had been watching infrastructure dashboards since 5 AM. Dev had been tracking transaction logs since before breakfast. The system had handled its first full afternoon of production traffic, and it had handled it without event.
There was no launch party. The team was too tired, and the nature of the work - the invisible kind, where success looks like nothing happened - did not lend itself to celebration in the usual way. What most people outside the team saw was: checkout is running. What the team knew was: the thing we built is holding.
A few days later, Priya sent a note to the team. She did not summarize the project or list its outcomes. She named the specific moments: Carmen’s original analysis that reframed the problem, the October near-miss and the four-day root-cause hunt, Tobias’s call on the data-sync issue, the two slip decisions, the Thursday morning when Dev sat down at 5 AM to watch the logs. She named the people. She said what they had done. It was a short note, and it was more accurate than any project retrospective I have read.
What This Kind of Work Asks
Section titled “What This Kind of Work Asks”Not all hard work produces visible artifacts. Not all fourteen-month projects produce a feature you can point to in a changelog. Some work produces something harder to name: a system that does not fail in the ways the old one did, a reliability that reads as absence rather than presence, a customer experience where the test of success is that nothing happens.
The checkout team built that. They did it under a constraint - keeping the old system running throughout - that multiplied their burden without multiplying their recognition. They made two decisions to slip, which took more discipline than launching on the original date would have. They caught two near-misses that most of the company never heard about, and they handled both correctly. The discipline to hold those calls, while stakeholders are asking questions and the calendar keeps moving, is not a skill that shows up in a performance review rubric. It is the skill of knowing what you are actually building and refusing to ship something that is not it.
That work deserves to be named clearly, because the thing that makes it hard is exactly the thing that makes it easy to undervalue: it worked. The fact that it worked looks, from the outside, like it was easy. It was not easy. It was the result of fourteen months of careful, compounding judgment made by people who were tired and still getting it right.
The store stayed open. The new system held. That was the job, and the team did the job.
We Picked Anchor Days and Both Sides Hate It. Good.
Section titled “We Picked Anchor Days and Both Sides Hate It. Good.”Last fall, we announced a new work policy: three “anchor days” per month when the whole team comes in together, and otherwise everyone chooses where they work. Within forty-eight hours, I had two very different emails sitting in my inbox. One was from a senior leader who felt we had “abandoned the culture we spent years building.” The other was from a fully remote employee who said she was “not interested in performing presence on a schedule.” Both were articulate. Both were angry. And I think both were partly right - which is exactly why I’m not reversing the decision.
The remote work debate has become almost purely tribal. Office-first leaders cite trust and spontaneity. Fully-remote advocates cite focus time and geographic freedom. Each side has genuine evidence. Each side also has a version of the argument that assumes its conclusion: of course collaboration suffers when you never see each other; of course you can recruit globally when you’re remote-first. What neither side has done is take the strongest version of the opposing case seriously.
I want to try. Not because I think the anchor day model is perfect, but because I believe it threads a needle that the binary framing misses entirely. Here’s the argument I find most honest - including the parts that make me uncomfortable.
What the Office-First Camp Gets Right (and Where It Overreaches)
Section titled “What the Office-First Camp Gets Right (and Where It Overreaches)”The in-person advocates have a real point that often gets drowned out by the “productivity” argument, which is their weakest ground. Productivity is hard to measure, easier to claim than to prove, and varies so much by role and person that blanket assertions about it are almost always misleading. When I hear someone say “people are just more productive in the office,” I stop listening, because that claim is doing work it cannot support.
But peel that away and there’s something underneath that holds up better: the texture of trust between people who haven’t met is different from the texture of trust between people who have eaten lunch together. That’s not magic or mysticism. It’s just true that certain kinds of rapport require physical presence to initiate, and that rapport makes hard conversations easier and ambiguous decisions faster.
There’s also a category of unplanned collaboration that genuinely is harder to replicate remotely. I’m not talking about the hallway-conversation mythology, where every company claims that their best product ideas came from bumping into someone at the coffee machine. That’s mostly retrofitted narrative. I’m talking about something more specific: the moment when someone overhears a problem being worked through and recognizes that they have a directly relevant piece of information. That kind of real-time ambient awareness of what colleagues are wrestling with is structurally easier when you’re in the same room.
Where the office-first camp overreaches is in treating these real benefits as justifications for mandatory full-time in-office presence. The benefits I just described - trust-building and ambient awareness - don’t require five days a week. They require reliable density. A team that is all physically present at the same time, predictably, even if infrequently, can capture most of those benefits. The argument for daily presence is, at bottom, an argument about managerial comfort - and that’s a different argument that deserves to be made honestly rather than dressed up as a cultural or collaborative necessity.
What the Remote-First Camp Gets Right (and Where It Overreaches)
Section titled “What the Remote-First Camp Gets Right (and Where It Overreaches)”The fully-remote advocates also have real points, and the most powerful one isn’t the talent pool argument, even though that argument is correct. The most powerful one is the commute argument.
Commuting is a significant daily cost that falls entirely on employees. It consumes time that cannot be recovered. It is physically and mentally exhausting for many people. It is expensive. It is a cost that workers bear so that companies can have the option of spontaneous in-person interaction. When you frame it that way - as a transfer of cost from employer to employee - the ethics of mandatory in-office presence become a lot less comfortable.
The talent and diversity argument is also real. A policy that requires physical proximity is structurally exclusionary along a number of dimensions: caregivers who need schedule flexibility, disabled workers for whom commuting is genuinely harder, people who cannot afford to live near a company’s office location. These aren’t edge cases. They represent a meaningful proportion of the workforce. When companies say “we need everyone in the office,” they are implicitly saying “we are limiting our pool to people for whom in-office presence is feasible.”
And focused, deep work - the kind that produces the most cognitively demanding output - does tend to happen better in environments that the worker can control. For many people, that is not an open-plan office.
Where the fully-remote camp overreaches is in treating all work interactions as equivalent. They’re not. Some work is genuinely better asynchronous and individually controlled. Some work - particularly work that involves building shared understanding of a problem for the first time, navigating interpersonal friction, or making consequential decisions under uncertainty - benefits from synchronous, in-person presence in ways that are not easily replicated. The fully-remote response is that video calls handle this, or that asynchronous documentation is better than meetings anyway. Both of those things are sometimes true and sometimes wrong, and the assertion that remote tools fully substitute for in-person interaction for all categories of work is, at this point, more ideological commitment than demonstrated fact.
The Binary Is the Trap
Section titled “The Binary Is the Trap”Here is the thing neither camp is saying: both sets of benefits are real, and they are not in conflict.
The office-first camp is correct that some categories of work benefit from in-person presence. The remote-first camp is correct that mandatory daily presence is a poor mechanism for getting those benefits, imposes real costs on workers, and forecloses access to talent that could strengthen the team. What follows from both of those things being true is not a compromise between two extremes - a halfhearted arrangement that satisfies no one. What follows is a third structure that doesn’t fit either model: intentional density for the things that need it, genuine flexibility for everything else.
The reason the binary persists is that it’s easier to manage. “Everyone in five days a week” is simple to enforce and requires no design. “Fully remote” is also simple and requires no real estate. A deliberate hybrid requires you to actually think about which work needs density and which doesn’t, schedule for it explicitly, hold the line on the commitment without policing the rest, and design physical space for intentional use rather than habitual occupancy.
That’s hard. Most organizations don’t want to do the design work. So they either pick a side, or they end up with what I’d call “accidental hybrid” - a policy that says “come in two to three days a week” with no specification of which days. That results in asynchronous work continuing to happen in person and collaborative work continuing to happen over video calls, just now with a mandatory commute mixed in. Accidental hybrid captures the costs of both models and the benefits of neither.
Anchor days are a specific alternative to accidental hybrid.
What Anchor Days Actually Mean in Practice
Section titled “What Anchor Days Actually Mean in Practice”An anchor day is not a “collaboration day” in the vague, aspirational sense. It is a specific day when a specific team is physically together for a defined purpose. The purposes that justify it - in our model - are the ones where in-person presence delivers most of its unique value: making shared decisions that require trust to stick, working through interpersonal or structural friction, kickoffs and retrospectives for significant projects, and occasional full-team time for the kind of ambient trust-building that compounds slowly.
Three per month sounds modest. It is. That is by design. If we’re honest about which work truly benefits from in-person presence, three days a month is probably more than enough to capture most of that value. The rest of the month’s work - individual production, asynchronous review, regular status sync, the ongoing coordination of an ongoing team - doesn’t require it.
What anchor days require that most office policies don’t is specificity of intent. You don’t show up and work on whatever you were going to work on anyway. The anchor day has a stated purpose, and that purpose reflects the work categories that we’ve decided in-person presence actually serves. A day when everyone comes in to sit at their desks on video calls for eight hours is not an anchor day - it’s an in-person simulation of remote work, and it deserves neither the commute cost nor the scheduling overhead.
The honest reason anchor days work, when they work, is that they make the implicit explicit. Every organization has moments that benefit from physical presence. In a fully remote organization, those moments either don’t happen or happen expensively through off-sites and travel budgets and periodic gatherings. In a full-time office organization, they happen continuously but without being distinguished from the ordinary, and they therefore don’t carry the intentionality that makes them most effective. Anchor days name those moments and schedule them deliberately.
The Hardest Objection
Section titled “The Hardest Objection”The strongest objection to this model is not the one I get from office-first leaders (“you’re not serious about culture”) or the one I get from remote advocates (“you’re imposing presence”). The strongest objection is this: anchor days require a level of organizational discipline that most companies don’t have, and without that discipline, they decay into accidental hybrid anyway.
That’s true. And I don’t have a fully satisfying answer to it.
What I have is this: the decay risk is real, but it’s a risk worth running because the alternatives have failure modes too. Full-time office presence degrades when the business case isn’t honest about its costs. Fully remote degrades when the investment in in-person connection events isn’t sustained, which it usually isn’t when a company hits a hard quarter and starts cutting travel budgets. Anchor days can decay into theater. So can off-sites. So can any intentional practice that requires sustained attention to execute.
The question isn’t which model is immune to organizational failure. None of them are. The question is which model, executed well, best serves the range of people and work that a company is responsible for. My answer is anchor days, precisely because they require you to be honest about why you want in-person presence - not “culture,” not “energy,” not “accountability,” but specific work that benefits from specific conditions.
I hold that answer loosely. I’ve seen it fail when the intent drifted. I’ve seen it succeed when the team held the line on what anchor days were for and protected the flexibility that was supposed to come with them. The model isn’t the guarantee. The discipline is. And discipline is something you choose, repeatedly, not something a policy provides.
Both emails I got after the announcement were right about something. The leader who worried about culture was correct - there is something that forms between people who share physical space, and we are not capturing all of it with three days a month. That’s an acceptable trade for the commute hours returned, the talent we can now recruit from further afield, and the signal we’re sending that we trust adults to manage their own environments. But “acceptable” is not “costless,” and anyone who tells you the hybrid model has no downsides is selling something.
The remote employee who didn’t want to perform presence on a schedule was also right about something. There is a difference between showing up because the work requires it and showing up to demonstrate that you’re committed. The anchor day model only works if we hold the line on the first and refuse to let it slide into the second. When I schedule an anchor day for a project kickoff and someone asks whether attendance is really necessary even though they could join remotely, my honest answer is: if you can do this work equally well remotely, we’ve failed at naming what the day is for. Either fix the intent or hold the commitment. Both options are on the table. Neither is comfortable.
The remote work debate isn’t going to resolve. The people who believe proximity is essential to organizational culture will not be persuaded by evidence, because the belief is partly about something real and partly about something else - about what it means to be a serious professional, about what management means, about what companies owe their cities. The people who believe remote work is simply better will not be moved either, because they’ve experienced something real: the recovered hours, the focused work, the access to roles they couldn’t access before. I’m not trying to resolve that debate. I’m making a more specific argument: that a deliberate hybrid with clear intent is better than either pole, and that “better” means something you can actually evaluate rather than something you have to believe.
Three days a month. Specific purpose. Real flexibility on the rest. That’s the bet.
Small Teams Don’t Have a Feedback Problem. They Have a Visibility Problem.
Section titled “Small Teams Don’t Have a Feedback Problem. They Have a Visibility Problem.”Every small product team has some version of this ritual. At the start of roadmap season, someone schedules a meeting, someone else opens a blank document, and for the next hour the team reconstructs what customers have been saying from memory, from chat logs scrolled back three months, from a thread buried in the support queue, from a note someone jotted during a call and never entered anywhere permanent. The feedback existed. It was never missing. That is exactly the problem.
There is a version of this you can live with. If your team is two people and your customer base is small, the pile stays manageable by feel. But somewhere in the growth from “a handful of customers” to “a few dozen,” the pile outgrows memory. You start making roadmap calls based on whoever spoke loudest in the last conversation, or whoever’s request happened to be the most recent, or whichever champion happens to be the most persistent this quarter - not because those are wrong signals, but because those are the only signals you can hold in your head at once.
When we started building Tidemark, we did not set out to solve a feedback collection problem. Most teams already collect feedback - they just collect it everywhere at once, in whatever channel the customer happened to use at that moment. The gap is not volume. It is visibility. You cannot prioritize what you cannot hold up and look at in a single place. That is the specific thing Tidemark does: it takes the scattered pile of customer signals that every small team accumulates and turns that pile into a single ranked, shareable roadmap. It launches next week, and this post is the clearest explanation I can give of why it exists.
Why the Pile Gets Out of Control
Section titled “Why the Pile Gets Out of Control”The mechanics are worth understanding, because they explain why the problem persists even in teams that think they have it handled.
Customer feedback does not arrive through a single channel. A request comes in through the support queue on Monday. A similar request surfaces in a live chat on Thursday. Someone on the sales team mentions the same need in a meeting recap, which gets logged in the notes document that lives in the shared drive and is opened twice a year. A long-time customer brings it up on a call, and the account manager sends a quick message to the product team via the chat tool. Nobody is being careless. Every one of those signals is real, and every person who recorded it did the right thing. The problem is that the signals live in four different places, formatted four different ways, with no consistent language and no obvious link to each other.
When it comes time to prioritize, the person building the roadmap does one of two things. Either they sit down and manually search every channel - the queue, the chat logs, the notes folder, the email thread - to find related signals and piece together a picture. Or they rely on pattern recognition: the things that have come up often enough to stick in memory, the things that were mentioned by a customer loud enough or important enough to stay top of mind. Both approaches work, sometimes. Neither scales, and neither gives the team a defensible answer to the question: “How do we know this is the right priority?”
That question matters more than it sounds. When a small team commits to a significant piece of work, the opportunity cost is real. Three weeks on a feature you thought customers wanted is three weeks not spent on something they actually need. The feedback was in the pile. You just couldn’t read the pile.
The Obvious Fix (and Why It Doesn’t Actually Fix It)
Section titled “The Obvious Fix (and Why It Doesn’t Actually Fix It)”The standard answer to this problem is a spreadsheet. Someone builds a feedback tracker with columns for date, source, customer name, request category, and priority level. For the first few weeks, it works. The team enters every incoming request. The document starts to feel authoritative. Roadmap conversations reference it.
Then the friction sets in. The tracker requires someone to actively route every incoming signal to it. Support tickets don’t automatically appear. Call notes don’t link to it. The chat tool doesn’t know it exists. The tracker is only as good as the person responsible for keeping it current, and that person has other jobs. Six weeks after launch, the tracker is three weeks behind. Two months after launch, nobody checks it anymore, and the team is back to memory and recency bias.
There is a deeper issue with the spreadsheet approach, too. Even a well-maintained tracker does not tell you what to do. It tells you what customers have asked for. Those are related but not the same thing. A list of requests, however thorough, still requires someone to sit down and impose order - to group related asks, assign weights, make judgment calls about which signals matter more than others. That work is hard and time-consuming, and it requires context about the customer that is often stored in someone’s head, not in the spreadsheet. The tracker captures the data. The ranking still happens by gut.
This is the loop we kept seeing when we talked to small teams during the year we spent building Tidemark. Not “we have no feedback.” Instead: “we have too much feedback in too many places and no clean way to turn it into a decision.” The tracker was a partial answer. We wanted to build the whole answer.
What Tidemark Actually Does
Section titled “What Tidemark Actually Does”Tidemark is a tool for small teams - typically five to fifteen people with a shared product responsibility - who need to go from scattered feedback to a defensible ranked roadmap without spending a week doing it.
The input side is designed to meet feedback where it already lives. You connect Tidemark to the channels you actually use: your support queue, your chat tool, your call notes, wherever you currently capture customer contact. Tidemark reads incoming signals and extracts the requests embedded in them - not just a verbatim log, but a categorized, normalized item that can be grouped with related signals from other channels. A support ticket saying “I wish I could filter by date” and a call note saying “customers keep asking about date range controls” land in the same place, associated with the same underlying request.
The ranking side is where Tidemark does its most specific work. Rather than producing a flat list, it produces a weighted ranking that accounts for factors you specify: how many distinct customers mentioned the request, how recently the signals arrived, how the request maps to the customer segments you care most about. Those weights are adjustable - this is your judgment, encoded, not a black box. You can look at any item in the ranked list and see exactly which signals fed it.
The shareable roadmap is the output. Not a spreadsheet, not a slide deck someone built for a quarterly review. A live document that reflects the current state of your ranked priorities and that you can share with customers, with stakeholders, with new team members. When something moves up the list because three more customers asked for it, the roadmap updates. When you mark something as “in progress” or “shipped,” the roadmap reflects that too.
The whole cycle - intake to ranking to roadmap - is designed to take hours, not days. And because the ranking logic is transparent, the conversation with a skeptical stakeholder shifts from “why do you think this is the right priority” to “here is the signal that moved this item up.”
Who It’s For, and Who It’s Not For
Section titled “Who It’s For, and Who It’s Not For”Tidemark is built for teams where the person doing product work is also doing five other jobs. A three-person startup where the founder is talking to customers, running the roadmap, and writing tickets. A small internal product team at a mid-size company with no dedicated research function. A two-person agency that builds and maintains software tools for clients and needs to keep multiple roadmaps straight.
It is not built for enterprise product organizations with dedicated research teams, specialized data infrastructure, and formal voice-of-customer programs. Those organizations have different problems and different tooling. Tidemark is not trying to be a platform. It is trying to be the thing that a small team can start using on a Tuesday afternoon and feel immediately useful.
The constraint is also real: Tidemark requires that you actually capture feedback somewhere to begin with. If your team’s incoming customer contact is entirely verbal and undocumented, Tidemark cannot read signals that were never recorded. The tool is built on the premise that most small teams do capture some feedback - it just lives in too many places to be useful. If you are starting from zero documentation, you would need to establish some capture habits first.
There is also an honest conversation to have about what Tidemark does not do. It does not talk to your customers for you. It does not generate product ideas. It does not make the hard call between two similarly-ranked requests when one of them is technically complex and the other one is not. Those are human decisions. What Tidemark does is make sure you are making those decisions with the actual signal, not just the signal you happened to remember.
What Changes When the Roadmap Is Real
Section titled “What Changes When the Roadmap Is Real”There is a practical shift that happens when a team starts working from a ranked roadmap with visible signal behind it. The roadmap conversations change in character. Instead of defending a priority by appeal to instinct or by arguing from the last customer call, you can show the thread. “This is ranked third because eleven customers in our target segment have asked for it in the last sixty days and we have not shipped anything in this area yet.” That is a different kind of conversation.
It also changes what you can share externally. A roadmap that is just a list of things the team intends to build is not very useful to a customer who is trying to decide whether to keep paying for your product or ask for something specific. A roadmap that reflects actual customer signals - that says, in effect, “here is what we are hearing from people like you, and here is how we are responding to it” - is a different kind of artifact. It is evidence of a process, not just a promise.
We are not claiming Tidemark solves the hard parts of product work. Deciding what to build is still the job. Reading customers accurately is still the job. Making tough calls about scope and tradeoffs is still the job. What Tidemark changes is the quality of the material you bring to those decisions. You stop working from a reconstruction of what customers said and start working from a record of it.
That difference is smaller than it sounds on a good week, when you remember everything and the signals align. It is enormous on a bad week, when priorities are contested and someone needs to show their work.
Tidemark opens for general access next week. If you manage a product backlog and spend more time reconstructing feedback than you spend acting on it, we built it for you. You can join the early access list at tidemark.io - we will send details as soon as the doors open.
The Year That Did Not Resolve
Section titled “The Year That Did Not Resolve”I have read a lot of year-end posts. They tend to follow a shape: the hard thing happens, then the writer figures something out, and by December there is a lesson that makes the difficulty feel earned. Even the posts that start by saying “this was my hardest year” tend to pivot, somewhere around the third section, toward a thread of meaning that retroactively justifies what the year cost. The difficulty becomes the point; the loss becomes a teacher.
This is not that post.
Not because nothing happened, and not because I am above finding meaning in difficult things. But because the year I am describing did not resolve in a way that allows for that kind of framing. I ended it holding two losses that are still just losses. I am writing this because I think there is something worth saying about that - about what it is like to close a year that does not give you the arc, and about the specific ways I made things harder than they needed to be.
Two Things That Broke at Once
Section titled “Two Things That Broke at Once”The project had been running for about two years when it ended. We were building a case management platform for a network of small social-service organizations - a tool that would replace the spreadsheets and the long email chains that their staff were navigating every day. My colleague Mara had designed the intake flow. Our technical lead, Dougie, had built most of the backend. I had written the grant narrative that funded the second phase and managed the relationship with the steering committee.
When the funding body made the decision to consolidate the cohort’s technology investments into a single vendor solution, the project ended. That is the clean version of why it ended. The fuller version is that I had spent six months making promises about our timeline that I knew were optimistic, and when we got to the milestone review in October, we were behind in ways that were visible and that I had not flagged in advance.
I do not think the timeline gap is what killed the project - the consolidation decision was probably coming regardless. But I also think I have to be honest about the fact that I handled the last stretch badly. I became protective of the work in a way that made me less honest with the funders and with my own team. I was so close to what we had built that I started managing optics instead of managing problems. That is a specific failure with a specific shape, and I do not want to lose it inside a broader narrative about structural forces that were outside my control.
The second thing: Marcus and I had been friends since graduate school, a friendship that had survived geography and different career paths and the usual drifts that happen when people’s lives stop overlapping directly. Early in the year, we had a disagreement that felt manageable at the time. By summer it had become clear that the disagreement had exposed something that had been accumulating for a while - a gap in how we understood what we owed each other. He told me, in a conversation I was not prepared for, that he felt I had been absent in a way that mattered to him during a period when he needed more than I was giving.
He was not wrong. I knew that even while I was getting defensive about it. The friendship did not end in a dramatic rupture. It changed into something more careful, more managed, and I miss what it was before I apparently failed to show up for it.
What the Situations Actually Asked
Section titled “What the Situations Actually Asked”The phrase “what the year asked of me” has a passive quality I want to push back on, because both of these situations were asking me to do specific things that I did not do.
The project asked me to be honest about slippage earlier than I was. The practice of flagging a timeline risk to a funder before the milestone review is not a complicated skill. I know how to do that. What I did not do was decide to do it, because I was protecting the project from scrutiny at exactly the moment when scrutiny was what it needed. I had poured two years into building that platform and I could not tolerate the idea of the funders losing confidence in us, so I managed the relationship rather than being straight with it. The project asked for honesty and I gave it careful messaging instead.
Marcus asked, over a longer period of time, for presence. Not a demanding amount of presence - he is not someone who needs constant contact. He was going through a stretch that required more of the kind of showing-up that I am capable of but that I tend to let slide when I am consumed by something else. I was consumed by the project for most of that year. I chose the project over the friendship in a way I did not name to myself until I had to hear him name it.
I want to be careful here about something. There is a version of this accounting that turns into a performance of appropriate contrition - a self-critical exercise that is its own kind of avoidance. The point is not to catalog the ways I fell short in order to demonstrate that I understand I was wrong. The point is to understand what actually happened clearly enough that it might not happen again in exactly the same form.
What I understand so far: I have a pattern of becoming so absorbed in the work immediately in front of me that I lose peripheral vision. I stop registering things that are not the project. The friendship was a peripheral item for ten months of the year, and Marcus paid for that with a friendship that is now different from what it was.
What I Got Wrong, Specifically
Section titled “What I Got Wrong, Specifically”There is a distinction I want to draw that took me most of the year to land on.
Getting something wrong is not the same as being the villain of it. I have noticed a pull, when I think about this year, toward two opposite moves: either I am not really responsible (the structural forces, the funder’s decision, the circumstances beyond my control) or I am entirely responsible in a way that makes the year into a story about my failures. Both of those moves are comfortable in their own way. One exonerates me; the other at least makes me the protagonist.
What is harder and more accurate: I made some specific errors in the project, and those errors made a bad outcome more likely and harder on the people I was working with. Mara spent the month of November rebuilding documentation that I should have been maintaining all along. Dougie found out about the project ending from the steering committee before I told him directly, because I was still trying to manage the conversation with the funders and I waited one day too long. These are concrete things that happened because of choices I made, and they had costs for real people who had done good work.
With Marcus: I did not fail to be his friend because I am a bad friend by nature. I failed to be his friend during a specific period because I was not paying attention, and when not paying attention costs something, that is a choice as much as anything else is.
What I got wrong, in both cases, is that I confused managing a situation with being in it. I was managing the project relationship with the funders instead of being honest with them. I was managing my availability with Marcus instead of actually being present, or at least being honest about not being present. Management at that level is a form of absence, and I kept choosing it because it felt like the responsible move - like I was holding things together. I was not holding things together. I was holding the appearance of things together while the things themselves were going badly.
That is the specific failure. The management crouch, the protective instinct that looks like leadership and is actually fear.
What I Am Choosing to Carry Forward
Section titled “What I Am Choosing to Carry Forward”I do not want to write a section called “what I learned” because that framing implies the lesson is finished, that I have integrated the experience and can now dispense its wisdom. I do not think I am there. So instead I want to say what I am choosing to carry forward, which is a more deliberate formulation. You pick the thing up and decide to bring it with you - not because it is light, but because you think you need it.
I am carrying the specific shape of the management-versus-presence problem. I have seen it clearly enough now that I think I can catch it earlier. That is not a guarantee. But I can, in theory, notice when I am starting to manage something instead of engaging with it - notice the protective crouch that I go into when I am behind or scared or over-invested - and ask myself what the honest move is. I do not know if I will make the honest move. But I am more likely to see the choice now than I was before.
I am carrying the awareness that the project work was genuinely good, and that it ended without the outcome we wanted, and that both of those things are true simultaneously. I am not going to let the ending cancel the building. We built something that worked for the organizations using it. The people on my team were skilled and committed. The project ended because of a funding consolidation decision and because of choices I made that made it harder to defend. All of that is true at the same time.
I am carrying the friendship as it is now - more careful, more managed, still there. Marcus and I still talk. It is different than it was, and I think that difference is probably durable, and I am not going to pretend that the changed version is fine with me just because it is what I have. But I am also not going to catastrophize it into something it is not. A friendship that survived me failing to show up and survived the hard conversation that followed is not nothing, even if it is not what it was.
What I am not carrying: the idea that the hard parts were preparing me for something. That they were supposed to happen so I could grow. I do not find that framework useful right now. Things happened, some of them because of forces I did not control, some of them because of choices I made, and I ended the year holding the results.
The Year Does Not Owe Me a Shape
Section titled “The Year Does Not Owe Me a Shape”The convention in year-end writing is to find the shape. What the year taught me. What I am taking into the next one. How the difficulty built me. I understand why that convention exists - it is satisfying, it makes the past feel purposeful, it gives the reader something to hold onto.
But the year does not owe me a shape. It just passed. What I do with what happened is a choice I make in the present, not a lesson the year deposited into me.
What I am choosing to do is understand it as accurately as I can, without rounding off the edges that do not fit neatly, and then make different choices where I can see clearly enough to make them. That is not redemption. It is not wisdom, exactly. It is just what you do with a year that did not resolve: you carry what you can use and you stop waiting for the rest to make sense.
The year cost something. Mara and Dougie deserved better from me in October. Marcus deserved better from me for most of the year before that. I got the project wrong in a specific way that I understand now, and I did not see it while it was happening. Those are facts I am going to live with, not facts I am going to alchemize into a better story than they are.
I do not know what the next year holds. I know what the last one cost, and who paid for some of it, and where the bill came from. That is enough to work with.
Appears in diff-pairs
Section titled “Appears in diff-pairs”- blog-post-long-form vs whitepaper (varies format)