Question and Answer
Sections are real reader questions in their natural phrasing, ordered by likelihood of being asked rather than by logical flow.
Frequently Asked Questions
Section titled “Frequently Asked Questions”The FAQ style organizes a piece around the questions a real reader would actually type or speak, ordered by how likely each one is to come up. It is not an outline disguised as questions; it is a structure built from the reader’s mental model of the topic, not the writer’s. Done well, a reader can land on any single question, get a complete answer, and leave - or stay and read the next one because it is the next thing they would naturally ask.
Three disciplines distinguish a real FAQ from a fake one. First, the questions must be in the reader’s voice, not the writer’s - “How do I cancel?” not “On the topic of cancellation.” Second, each answer must be self-sufficient. A reader who arrived via search or a deep link should not need to read the preceding question to make sense of the current one. Third, the order is empirical: which questions come up most often, asked first. Logical flow is a secondary concern, and sometimes a casualty.
The FAQ is fundamentally a multi-entry-point format. The reader is not expected to read it linearly. This is its strength when the audience is heterogeneous and its weakness when the material needs to build a single conceptual model: each answer in isolation cannot do what a sustained explanation can.
Structural conventions
Section titled “Structural conventions”- Each section header is a question phrased the way a reader would actually ask it, not a topic
- Questions ordered by frequency or urgency of being asked, not by logical dependency
- Each answer is self-contained - a reader arriving at one question via search should not need to read earlier ones
- Answers are direct and lead with the answer, not the setup (“Yes, you can. To do it…” not “Many users wonder…”)
- Cross-links between related questions are explicit when an answer depends on context from elsewhere
When to use
Section titled “When to use”Support documentation where readers arrive via search, product help pages with heterogeneous audiences, onboarding material covering questions of varying scope, policy or compliance documents that need to be navigable.
When not to use
Section titled “When not to use”Material that builds a single conceptual model the reader must absorb in order, narrative or reflective writing, content where the reader has not yet formed any questions, tutorials with a single intended path.
Pairs well with
Section titled “Pairs well with”technical-writer, instructional, technical-reference, readme
Often confused with
Section titled “Often confused with”procedural: A how-to tutorial assumes a single ordered path - step one, then step two, then step three - and the reader is expected to follow that path. An FAQ assumes many readers arriving at many points, each needing only their one answer. If the material has one correct order, it is a tutorial; if it has many, it is an FAQ.
- Each section header is a question phrased the way a reader would actually ask it, not a topic label
- Questions are ordered by frequency or urgency of being asked, not by logical dependency
- Each answer is self-contained - a reader arriving via search should not need to have read earlier ones
- Answers lead with the answer (“Yes, you can. To do it…”) rather than the setup (“Many users wonder…”)
- Questions are in the reader’s voice (“How do I cancel?”) not the writer’s (“On the topic of cancellation”)
- Cross-links are explicit when one answer depends on context from another
Anti-patterns
Section titled “Anti-patterns”- Writing an outline disguised as questions, with topic headers reworded into question form - A real FAQ is built from the reader’s mental model; questions in the writer’s framing rather than the reader’s voice defeat the entire structure.
- Writing answers that assume the reader has read the previous question - The FAQ is a multi-entry-point format; an answer that is not self-contained fails the reader who arrived by search or deep link at that one question.
- Arranging the questions as a single ordered path the reader is expected to follow step by step - One correct order through the material is a how-to tutorial, a confusable neighbor; an FAQ assumes many readers arriving at many points, each needing only their one answer.
Failure modes
Section titled “Failure modes”- Over-applies the self-contained, ordered-by-frequency discipline until the piece fragments into a sprawl of isolated entries that, read through, never assemble into any coherent picture of the topic - The independence of answers is a strength for searchers, not a license to abandon structure; group and cross-link related questions so a linear reader still comes away with a whole, and reach for a sustained explanation when the material genuinely needs one model.
- Pushes self-sufficiency so far that every answer repeats the same shared context, padding the document with duplicated preamble across questions - Repeat only the context an isolated answer truly needs; where several answers share a foundation, state it once and cross-link rather than re-explaining it in each.
Instruction
Section titled “Instruction”Write using a frequently asked questions structure. Each section header is a question phrased theway a real reader would ask it, in their voice, not yours. Order the questions by how likely orurgent they are to come up, not by what would make a tidy outline. Each answer must beself-contained - a reader who arrived at one question via search must not need to read the othersto understand it. Lead each answer with the answer itself, not setup. If two answers depend onshared context, repeat the context or cross-link explicitly. The reader is not reading top tobottom; treat every question as an entry point.Related
Section titled “Related”Pairs well with
Section titled “Pairs well with”Technical Writer, Instructional, Technical Reference, README
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
Async-first standups: FAQ for the 30-day trial
Section titled “Async-first standups: FAQ for the 30-day trial”What if I forget to post?
Section titled “What if I forget to post?”Most days, no one will notice for a few hours. By 11am local your manager will ping you. If you forget twice in a week, the team lead will check in. The post is meant to take 90 seconds. If you are forgetting, the friction is probably not memory, it is that the format is not working for you. Tell us, do not just absorb the miss.
How do blockers actually get resolved without the meeting?
Section titled “How do blockers actually get resolved without the meeting?”Three fields, one of them is “blockers.” If you have a blocker, you @mention the person who can unblock you in the same post. They get a notification. If they do not respond within their working hours, you escalate to the team channel. The standup meeting was not resolving blockers faster than this anyway. We checked: in the last 10 standups, 2 blockers were resolved in the meeting itself, the other 6 were resolved in side conversations afterward.
I am new to the team. Does this work for me?
Section titled “I am new to the team. Does this work for me?”Honest answer: it is harder for new joiners and we know it. For your first 30 days, you get a 20-minute weekly sync with your onboarding buddy. Use it for the questions the standup used to surface for you. After 30 days, you will know who to ping for what, which is the actual skill the standup was teaching you, just slower.
What about the social part? I liked seeing everyone.
Section titled “What about the social part? I liked seeing everyone.”This is the most common pushback and it is real. We are not removing all sync time. We are keeping the Friday team call (45 min, half social, half demos). The standup was never very social anyway, it was 11 people on mute waiting their turn. If you want more human contact than Friday provides, propose something. We will fund it.
Do I have to post if I have nothing to report?
Section titled “Do I have to post if I have nothing to report?”Yes, even one line. “No movement on X, picking up Y today, no blockers.” The post is not just status, it is presence. Skipping creates ambiguity: did you not work, or did you forget to post? One line resolves that in 10 seconds.
What if my manager wants more detail than three fields?
Section titled “What if my manager wants more detail than three fields?”That is a one-on-one conversation, not a standup conversation. The three fields are for the team. If your manager needs more, they should be getting it in your weekly 1:1, not by reading every standup post.
Will Priya and Arjun finally be in the loop?
Section titled “Will Priya and Arjun finally be in the loop?”That is the main reason we are trying this. They currently attend 3.2 of 5 sessions. With async, the floor for “being in the loop” stops being “you woke up at 9:30pm.” We will measure this. If after 30 days they report still feeling out of the loop, the experiment failed even if attendance numbers look good.
How will we know if it is working?
Section titled “How will we know if it is working?”Four signals, measured at day 30:
- Self-reported clarity on what teammates are working on (survey).
- Self-reported attendance burden (especially for India-based engineers).
- Time to blocker resolution (compared to a baseline we capture this week).
- Number of “I did not know you were working on that” moments in retros.
What if we hate it?
Section titled “What if we hate it?”We go back. The proposal is a 30-day trial, not a permanent change. The reversal cost is one team meeting. Do not catastrophize and do not silently endure. Speak up at day 15.
Can I still hop on a call if I want to?
Section titled “Can I still hop on a call if I want to?”Yes. Nothing prevents two people from getting on a Zoom to work through something. The thing we are removing is the mandatory daily group call, not the option to talk.
Who do I talk to if I have a concern not covered here?
Section titled “Who do I talk to if I have a concern not covered here?”DM the team lead. Concerns shape the trial. The FAQ will be updated as new questions come in.
Morning routines: FAQ
Section titled “Morning routines: FAQ”What if I have kids?
Section titled “What if I have kids?”Then your routine has to be one of two things: shorter, or shared. Most people pick neither, try to do an hour-long routine on a 20-minute window, fail, and conclude they cannot do routines. You can. You just need a 20-minute version. Or you make breakfast prep, lights on, and a glass of water the routine itself, and let the kid be part of it. Routines built around kids tend to be more durable than the ones built in opposition to them.
What if I am not a morning person?
Section titled “What if I am not a morning person?”The honest answer is that “morning person” is partly chronotype and partly habit. The chronotype part is real and you cannot will yourself into being a 5am person if you are wired for 11pm. But most people who say “I am not a morning person” are working with a 30-year habit of treating mornings as something to survive. Try the routine for two weeks before deciding which one you are. The first three days are not a fair test.
How long until it feels normal?
Section titled “How long until it feels normal?”Roughly: three days to start, two weeks to feel less effortful, six to eight weeks for it to feel like the thing you do rather than the thing you are trying to do. The number floating around as “21 days” is too short for most behavior changes that involve waking up. Plan for two months. Treat anything that sticks past day 14 as encouraging, not a guarantee.
Do I have to put my phone in another room?
Section titled “Do I have to put my phone in another room?”You have to put your phone somewhere your morning self cannot easily reach it. For most people that is another room. For some it is a drawer. For some it is across the bedroom on a charging dock that doubles as the alarm. The mechanism matters less than the property: when you wake up, the phone should not be the path of least resistance. If you find yourself bargaining with the rule, the rule is working.
What if I just want to scroll for 10 minutes first, what is the harm?
Section titled “What if I just want to scroll for 10 minutes first, what is the harm?”The harm is that the first input of the day calibrates your nervous system for the rest of the day. Ten minutes of email, news, or social media in the first conscious minutes puts you into a reactive mode that is hard to climb out of by 9am. If you want to scroll, do it after the routine, not before. The 10 minutes is rarely the issue. The order is.
What should be in the routine?
Section titled “What should be in the routine?”The honest, boring answer: water, light, movement, and a brief plan for the day. In any order, any version. Cold water on your face counts. Stepping outside for two minutes counts. Three pushups count. Writing three priorities on a Post-it counts. You can decorate this list with meditation, journaling, reading, cold plunges, sun salutations, espresso ceremonies. Decoration is fine. Decoration is not the engine.
What if I wake up and immediately have to take care of someone else?
Section titled “What if I wake up and immediately have to take care of someone else?”Then your routine starts after that. Or your routine is part of that. Or you accept that you have a 5-minute routine and not a 60-minute routine. The morning routine is not a moral category. It is a shape that fits the morning you have. Some seasons of life have no morning routine, and that is okay.
Should I do this on weekends?
Section titled “Should I do this on weekends?”A weakened version, yes. The “everything different on weekends” pattern is part of what makes Monday hard. Wake within an hour of the weekday time. Do the smallest version of the routine. The point is not weekend austerity, it is that the system you have built does not collapse every Friday night.
I tried before and it did not stick. What was I doing wrong?
Section titled “I tried before and it did not stick. What was I doing wrong?”Probably one of: too many new behaviors at once, no plan for the day it falls apart, the routine was for the person you want to be rather than the person you are, or you were tracking “did I do the routine” instead of any outcome that matters to you. The honest fix is usually “do less, for longer.” Start with one thing. Two weeks. Then add.
How do I keep it going past the first month?
Section titled “How do I keep it going past the first month?”Have a recovery plan. Decide in advance what counts as falling off, what counts as a normal bad day, and how you get back. The people who sustain routines are not the ones who never miss. They are the ones who miss without quitting.
Frequently Asked Questions on: Choosing between Postgres and DynamoDB
Section titled “Frequently Asked Questions on: Choosing between Postgres and DynamoDB”What did we actually decide?
Section titled “What did we actually decide?”We are shipping the Lattice Notify notification system on Postgres with a queue in front. If real volume crosses 2M events/day on a 30-day rolling average, we trigger a planned migration to DynamoDB the following sprint. Ana owns the build; Marcus has a preserved Dynamo design in the design-docs repo for the trigger case.
Why not just go with DynamoDB now?
Section titled “Why not just go with DynamoDB now?”Two reasons. First, our four-person on-call rotation has not operated DynamoDB in production, and the team agreed that adding a storage system the rotation cannot debug is unsafe at launch. Second, the 10x growth scenario is conditional on the Slack-partnership deal closing (currently 60% per the CRO). At that probability, the expected cost of running two storage systems for a year is higher than the expected cost of a deferred migration. The decision is rational only if you believe the Slack deal is closer to certain than the CRO thinks it is.
What happens if the Slack deal closes faster than expected?
Section titled “What happens if the Slack deal closes faster than expected?”We hit the 2M events/day trigger and run the Dynamo migration project the following sprint. Marcus’s preserved schema design shortens the lead-in. Realistic timeline: 3-6 weeks of work, two engineers, with a known migration plan rather than a discovery project. This is the worst case in our scenario tree, and it is recoverable.
Why are we using a queue in front of Postgres?
Section titled “Why are we using a queue in front of Postgres?”The launch access pattern is write-heavy and time-ordered. A queue (SQS or our internal event bus, TBD by Marcus’s schema review) absorbs spikes so writes to Postgres stay paced. It also gives us a clean buffer if we later want to write to a second store in parallel during the migration window.
Who decided this and when?
Section titled “Who decided this and when?”The architecture meeting on Wednesday 2026-05-13 at 2pm Pacific. Decision committed to channel on Friday 2026-05-15 by Ana (Tech Lead, Notifications), with input from Marcus (Senior Eng), Priya (PM), and the on-call rotation. Sprint planning ran Friday afternoon against the decision.
Why is Ana the owner if she leaned Postgres? Isn’t that confirmation bias?
Section titled “Why is Ana the owner if she leaned Postgres? Isn’t that confirmation bias?”The Wednesday meeting moved off the “which database is better” framing into “how confident are we in the Slack deal.” Once the team agreed the question was probabilistic, Ana’s lean and Marcus’s lean both became conditional rather than oppositional. The current plan covers both of their concerns: ship on Postgres now (Ana’s preference) with a binding trigger for migration if the volume scenario she discounted actually materializes (Marcus’s concern made operational).
How does this affect the on-call rotation right now?
Section titled “How does this affect the on-call rotation right now?”It does not. The four-person rotation stays on one storage system at launch. If the migration trigger fires, we will revisit the rotation composition before the second system goes live - likely by adding training time and possibly a fifth rotation member.
What happens to Marcus’s prototype work?
Section titled “What happens to Marcus’s prototype work?”Preserved in the design-docs repo under notifications/dynamodb-schema-v1.md with a status header of “deferred design, ready to revive.” Not deleted, not productionized. If the trigger fires, the prototype becomes the starting point for the real schema rather than a from-scratch effort.
Can I read the full decision document?
Section titled “Can I read the full decision document?”Yes. The decision log is in docs/decisions/2026-05-15-notification-storage.md. It includes the options considered, criteria used, and the reasoning Ana captured at decision time. The full set of architecture meeting notes is in the engineering wiki under Architecture Meetings / 2026-05-13.
What if I think this is the wrong call?
Section titled “What if I think this is the wrong call?”The 2026-Q3 architecture review is the formal moment to revisit. Bring real volume data and the current Slack-deal status; both will be different inputs than what we had this week. If you have a strong objection before then, talk to Ana directly; the decision is not sealed, just committed for execution.
Is Insights still shipping this quarter?
No. Insights is not shipping in Q3. The new delivery target is Q1 of next year.
Why was it cut?
A billing-system migration that began in July ran significantly longer than the engineering team estimated. The migration was not optional - it blocked a compliance deadline - and it could not be deferred. It consumed the engineering capacity that was allocated for Insights. The team finished the migration, but finishing it meant Insights would have arrived in September half-built. Shipping a half-built dashboard would have created more friction for customers than it removed. The team made the call to delay rather than deliver something that required immediate workarounds.
What will customers get before Q3 ends?
A CSV export of the underlying Insights data ships in September, before Q3 closes. Customers who need to work with their data now can export it and analyze it in a spreadsheet or BI tool of their choice. This is not the interactive Insights dashboard - it is a bridge so customers are not empty-handed while the full product is completed.
When exactly will Insights ship?
The current target is Q1. A specific release date will be confirmed in October once Q4 planning closes. The billing migration is finished; there is no comparable blocker in the current roadmap.
What should I tell customers who ask why this slipped?
Tell them the engineering team hit a mandatory billing-system migration that ran longer than expected and could not be moved. The team chose not to ship Insights half-built rather than put customers in a position of working around gaps in a product that was supposed to remove friction. The CSV export is available now; Insights follows in Q1. (For the specific Q1 date, see “When exactly will Insights ship?” above.)
Is Q1 a firm date, or could this slip again?
We have strong reasons to believe Q1 will hold. The migration that caused this delay is complete. No comparable scope item is in the current roadmap. If anything threatens the Q1 date, the team will surface it immediately - the goal is to never repeat this kind of late notice.
What does Priya need to actually do work on Day 1?
Section titled “What does Priya need to actually do work on Day 1?”Access first, then context. Before she arrives, provision her accounts for the code host, the deployment system, the chat tool, and the ticket tracker. Nothing stalls a first day like waiting on an approval chain that could have been handled the Friday before.
Day 1 ends when she can pull the main repository, run the service locally, and read recent deploys. She does not need to understand the codebase yet - just know where it lives and that her machine can reach it.
When should she write her first line of production code?
Section titled “When should she write her first line of production code?”By the end of day three, if possible. The instinct to protect a new engineer with a long orientation usually backfires. A week of reading documentation and sitting in meetings without touching anything erodes confidence without building it.
Pair her on a small change in week one: a configuration fix, a test gap, a logging line. Size does not matter. What matters is that she opens a pull request, gets feedback, and watches it deploy. That cycle, experienced once, is worth more than a day of orientation. (See “How do I pick her first solo task?” for her week-two target.)
How do I pick her first solo task?
Section titled “How do I pick her first solo task?”Look for a change that is small, self-contained, and genuinely useful - not a cleanup task invented for training purposes. Engineers can tell the difference, and it matters to them.
Good candidates: a missing error message that real users hit, a test that was skipped when the code shipped, a small behavior a bug report flagged and nobody got to. Bad candidates: anything requiring context across three services, anything on the current sprint’s critical path.
Assign it by end of week one so she can ask questions that actually matter while you are still pairing.
When does she join on-call, and how do I prepare her?
Section titled “When does she join on-call, and how do I prepare her?”Not in week two. On-call requires knowing what to do when things break, and that knowledge only comes from having shipped a few things first.
The right preparation is a written runbook she can read in advance, a shadowing shift where she watches someone else handle a page, and one explicit conversation about who to call at 2am if she is stuck. That conversation matters more than the runbook. A reasonable target for her first solo shift is six to eight weeks in.
How do I know if she feels like she belongs, not just functions?
Section titled “How do I know if she feels like she belongs, not just functions?”Watch for whether she volunteers opinions in planning meetings, asks questions that are not purely task-related, and says “we” when talking about team decisions. An engineer who belongs speaks as a member; one still arriving speaks as a visitor.
If those signals are absent by the end of week two, do not wait. Have the direct conversation: what is unclear, what feels uncomfortable, who she has not met yet. The social side often stalls not from hostility but from nobody explicitly making room.
Why are you writing to me after ten years?
Section titled “Why are you writing to me after ten years?”Last month, I put one of my direct reports - Kenji - on a project he was not ready for. I watched him struggle through the first three weeks, checked in more than I probably should have, and somehow managed not to take it back from him. The moment I stopped hovering, he found his footing.
That night I sat at my kitchen table trying to figure out where I had learned to do that. And I kept coming back to you.
What do you think I did, exactly?
Section titled “What do you think I did, exactly?”You gave me the Alderton account in March of my first year, when I had maybe eight months of real client experience and the project was going to run for eighteen months. I remember telling you I was not ready. You said: “I know. That is why I am giving it to you now instead of later.”
Then you did the harder thing: you stayed available without taking over. You asked questions that pointed me toward decisions rather than making them for me. When I got the pricing wrong in the second quarter and had to go back to the client, you did not step in. You helped me prepare for that conversation, and then you let me have it.
How much patience did that cost you?
Section titled “How much patience did that cost you?”More than you ever let on. I was slow. I asked you things I could have figured out myself. I sent you drafts that needed more work than I had put into them. I know this now because Kenji sent me the same kinds of drafts last month, and it took real effort not to rewrite them for him.
You responded to every one with a question that made me see what I had missed. That is not a natural response. It is a practiced one, and it costs something each time.
What did it make possible?
Section titled “What did it make possible?”The Alderton project ran fine - not brilliantly, but fine. That is not what I am thanking you for. What you made possible is this: I know what it looks like to hand someone a project that is bigger than they think they are, stay close, and not take it back. I did not figure this out on my own. I absorbed it from watching you do it to me.
When Kenji’s project wrapped last week, he sent me a note saying he thought he had learned more in a month than in the previous two years. I have some idea what that means to receive, because you made it possible for me to receive something like it once.
That is what I wanted you to know.
What do I do when I feel the urge to check just one more thing?
Section titled “What do I do when I feel the urge to check just one more thing?”You notice the urge, and then you put the phone down anyway. That is the whole practice, at first.
The urge does not mean you are doing it wrong. It means you have spent years training the checking reflex. The impulse to verify, to respond, to stay current - it does not dissolve because you decided to rest. It shows up on schedule, usually in the first hour.
What helps: name it. “I want to check. I am choosing not to.” Then do something that uses your hands or body. The urge has a half-life. If you do not act on it within ten minutes, it usually quiets.
Does a rest day actually help? I have tried this before and it did not stick.
Section titled “Does a rest day actually help? I have tried this before and it did not stick.”Yes - but not in the way most people expect.
The benefit is not that you recharge. It is that the day without work clarifies what in the other days actually mattered. You return the next morning with a sharper sense of what is worth doing and what was just motion. The clarity is not dramatic. It shows up as slightly better judgment - fewer half-started things, less time on tasks that would not have been missed.
The first few attempts did not stick because the benefit is not visible on the rest day itself. You see it later in the week.
What counts as rest, and what does not?
Section titled “What counts as rest, and what does not?”Rest is the absence of the posture of production - the monitoring mode, the always-on readiness to respond, the sense that time must be justified by output.
A long walk counts. A slow meal counts. Reading something with no professional application counts. What does not count is checking the inbox “just to make sure nothing is urgent,” or doing work you enjoy and calling it rest.
The test is not what you are doing. It is whether you have put down the obligation to produce.
How long before the day stops feeling like lost time?
Section titled “How long before the day stops feeling like lost time?”Several weeks for most people. A few months before it feels natural.
The feeling of lost time does not pass quickly because it is measuring against a real cost - there is work you could have done and did not. The reframe that helps is not “this time was not wasted” but “the return is not visible on the rest day itself.”
You do not see it that day. You see it later in the week, when a problem resolves faster than it should have, when you are not carrying the weight of an unbroken stretch. That is what the day returns: not energy, exactly, but steadiness that makes the work sharper when you come back to it.
Howard Regan is retiring. You probably have questions.
Section titled “Howard Regan is retiring. You probably have questions.”Wait - I don’t think I’ve actually met Howard. Who is he?
Howard Regan has worked in Operational Continuity at Mercer-Blaine for twenty-six years. For most of that time he held the same title: Senior Coordinator. If you joined in the last several years and your path never crossed the ops continuity team, you may not know his name. But you have almost certainly been on the receiving end of something he kept from breaking.
What did he actually do here for twenty-six years?
His formal job was coordinating across teams when a process or system stopped working the way it was supposed to. In practice, that meant Howard was the person you called when no one else knew the answer, when the documentation was out of date, and when the problem predated anyone else currently employed. He could tell you which vendor contract had the clause you needed, why the old approval workflow was structured the way it was, and what the predecessor team had tried in 2009 that did not work. He held the institutional memory that no system stores.
Why does this feel like a bigger deal than most retirements?
Because Howard was the reason several people still work here - not through any formal program. He did not run mentorship initiatives or hold office hours. He just noticed when someone was struggling, asked one careful question, and let that person talk. He stayed after hours to walk a new hire through a process she was too embarrassed to say she did not understand. He reviewed a junior analyst’s project plan without being asked, marked three serious risks in red, and returned it without telling anyone. That analyst is now a senior lead. There are others.
He was in the same role for most of his career. Was that a choice or was he passed over?
He was offered advancement more than once. He turned it down each time, and his reason was consistent: he was not interested in running meetings about the work. He was interested in the work. That choice cost him title and salary progression. It gave everyone else stability, accuracy, and a phone number to call in a crisis.
What actually changes now that he’s gone?
A lot of informal infrastructure we did not know was a single person. The ticket tracker will still route issues. The shared folders will still be there. What will be missing is the person who knew which folder was mislabeled, which ticket described the wrong problem, and what the actual situation was. We will find out what Howard knew by encountering the gaps he filled.
Did the launch actually hold?
Section titled “Did the launch actually hold?”Yes. The final cutover ran under peak load and cleared without a production incident. Error rates stayed within normal bounds, the on-call rotation had nothing to escalate, and the old checkout is standing down. After fourteen months of carrying two codebases in parallel, a clean launch night was the right ending.
Why did this take fourteen months?
Section titled “Why did this take fourteen months?”Because the old checkout stayed live the entire time. The team built the replacement while the original processed orders every day. Every integration had to run in parallel, every data migration had to be reversible, and every change had to account for two systems coexisting. Fourteen months under that constraint is not slow - it is what that constraint costs.
The launch got pushed back twice. What happened each time?
Section titled “The launch got pushed back twice. What happened each time?”The first slip came in month six. Integration testing with the payment provider uncovered a credential-scoping problem the original design had missed: the new system was requesting broader permissions than it needed, and the provider would have rejected the connection in production. The team moved the window back five weeks to redesign that surface properly.
The second came in month eleven, when a routine version update to a session-management dependency broke the checkout recovery path for interrupted orders. Three weeks before the planned go-live, the team pushed the date four weeks and rebuilt the recovery path on a more defensible foundation. Both times, pushing was the right call.
Were there any other close calls along the way?
Section titled “Were there any other close calls along the way?”Two, and neither moved the schedule. In month eight, a load test exposed a database connection pool sized for average order volume, not promotional peak. On a normal Tuesday the new system would have been fine; on a high-traffic Friday it would have cascaded. The team caught it, resized the pool, and re-ran the test suite - fast unplanned work, no delay.
The second happened during the parallel-run phase in month thirteen. An engineer running an unrelated query noticed duplicate rows in the audit table: a legacy batch job had been double-writing order records into the shared table throughout the parallel run. Uncaught, this would have imported corrupted audit data on cutover night. One engineer’s curiosity while working on something else prevented it.
What does this mean for cart abandonment?
Section titled “What does this mean for cart abandonment?”We will have a complete picture after a full measurement cycle, but the early signal is positive. Checkout completion is running above the prior-year baseline. The reason this project existed was to fix a real problem for real customers, and the early numbers suggest it worked.
Why can’t we just stay fully remote?
Section titled “Why can’t we just stay fully remote?”You lose things that remote work cannot replicate: trust that forms through unplanned physical moments, problem-solving that spills across meetings, and the ability to read a colleague as a whole person rather than a grid of faces on a screen. These are not soft abstractions - they shape how freely people disagree, how quickly conflict resolves, and whether someone speaks up when they notice something going wrong. Fully remote preserves focused individual work and a wider talent pool, which are real advantages worth keeping. Anchor days are how you hold onto those advantages while recovering what remote cannot give back.
Why not just require everyone in the office five days a week?
Section titled “Why not just require everyone in the office five days a week?”Full-time mandates narrow your hiring pool to whoever lives within commuting distance, cost employees hours every week they were previously keeping, and typically produce a workplace full of people sitting at desks doing the same work they could do from home. The goal of a return-to-office policy should be to create conditions for genuine collaboration, not to demonstrate oversight. A blanket five-day mandate does not accomplish the former; it performs the latter.
What makes “anchor days” different from just picking two mandatory days?
Section titled “What makes “anchor days” different from just picking two mandatory days?”Intent. Random mandatory days put bodies in a room. Anchor days are the days when work that genuinely needs in-person presence gets scheduled: project kickoffs, decisions that carry high conflict risk, whiteboarding sessions that lose something when translated to a shared document. When in-person time is built around specific high-value activities, people arrive with a reason to be there. When the mandate is simply “Tuesdays and Thursdays because we said so,” people arrive, put on headphones, and do exactly what they would have done at home.
What about team members who live too far to make this work?
Section titled “What about team members who live too far to make this work?”This is the honest catch: a deliberate hybrid model sets a geographic expectation that not every current employee - or every potential hire - can meet. The policy needs to name this clearly. Anchor days require proximity, and proximity matters when hiring. That is a real constraint, not a failure of the policy. A transparent statement - “you need to be within reasonable commuting distance of the office” - does less harm than a policy that pretends location does not matter and then surprises employees when it turns out to matter a great deal.
What stops leadership from just adding more anchor days until we’re back at five?
Section titled “What stops leadership from just adding more anchor days until we’re back at five?”Nothing structural, which is why the policy has to commit to a ceiling and hold it. Two to three anchor days is the right range; beyond that, the policy stops being hybrid and becomes office-first with a branding problem. If leadership cannot credibly commit to that ceiling, the trust problem is not about the policy - it is about the relationship between leadership and the team, and a remote-work policy cannot fix that. The answer is public accountability: announce the number of anchor days, give employees a clear channel to flag when additional days are being added in practice, and treat scope creep as a policy violation, not a management prerogative.
Tidemark: Your Questions Answered
Section titled “Tidemark: Your Questions Answered”What is Tidemark?
Section titled “What is Tidemark?”Tidemark is a tool that collects customer feedback from wherever your team already stores it - support tickets, chat logs, interview notes, shared documents - and turns it into a single ranked roadmap your whole team can see and share. It launches publicly next week.
Who is it for?
Section titled “Who is it for?”Small product teams drowning in scattered feedback. If your team is copying quotes into a spreadsheet, voting on sticky notes, or arguing in a chat thread about what customers “really want,” Tidemark was built for you. It is not aimed at enterprise research programs; it is designed for teams of roughly two to twenty people who need to make sense of feedback without a dedicated research operation.
How does it work?
Section titled “How does it work?”You connect your existing sources - a ticket tracker, a shared document folder, a feedback form - and Tidemark pulls in the raw responses. It groups them by theme, surfaces the most-requested items, and lets you rank and annotate them. The output is a live roadmap view you can share with a link. Viewers do not need an account.
What makes it different from a spreadsheet or a project tracker?
Section titled “What makes it different from a spreadsheet or a project tracker?”A spreadsheet does not read your feedback for you; Tidemark does. A project tracker assumes you already know what to build; Tidemark helps you decide. The key difference is automatic grouping: Tidemark clusters similar requests, so “the export button is broken” and “I cannot download my data” appear as one item instead of two. That step is where most teams fall behind when doing this by hand.
(For how Tidemark connects to your existing sources, see “How does it work?” above.)
When does it launch, and how do I get access?
Section titled “When does it launch, and how do I get access?”Tidemark launches publicly next week. To get early access and a walkthrough from the team, join the waitlist at the link below. If you are an existing customer, you will receive a direct invite before the public launch date.
Is it free?
Section titled “Is it free?”There is a free tier for teams of up to five people. Paid plans are available when you need more connected sources, more collaborators, or the ability to export your ranked roadmap to other tools. Pricing details are on the Tidemark website.
What happened this year?
Section titled “What happened this year?”Two things broke inside three months, and neither resolved cleanly. A project I had spent two years building - a community platform for independent educators - closed without finding the audience it needed. And a friendship that had run like a current through almost a decade of my adult life changed in ways I did not choose and am still working to understand. Both losses are real. Neither came with a ceremony or a clear end point.
Did the project actually fail, or just not go the way you wanted?
Section titled “Did the project actually fail, or just not go the way you wanted?”It failed. I know what people mean when they frame it softly - they mean it did not reach its goals but taught you things. That framing is not wrong, but it is incomplete here. The platform closed. The people using it lost access to something they had built habits around. I ran out of runway before I found what I needed to find. That is a failure. I am trying to hold it without softening it.
What did you get wrong?
Section titled “What did you get wrong?”I mistook momentum for traction. We had activity - users talking to each other, good session numbers, genuine engagement - and I read that as proof we were on the right path. I did not look hard enough at whether the people most engaged would ever pay, or refer others, or stay when something easier appeared. I built for the version of the audience I wanted, not the one I had.
What about the friendship - what changed?
Section titled “What about the friendship - what changed?”It did not end in a confrontation. It changed slowly, then conclusively. The circumstances that had held us close shifted over time, and the person reasonably changed alongside them. I expected consistency I had no real right to expect. During the period when the friendship needed flexibility from me, I offered pressure instead. I handled it poorly.
Are you okay?
Section titled “Are you okay?”Mostly. The year cost something real and I am not going to pretend otherwise. What I am trying to resist is the reflex to find a lesson that redeems the losses - the assumption that hard things must be secretly useful or they do not count. Some of what happened this year was just hard. That is what I want to carry forward: the year as it actually was, without the redemption arc I did not earn.
Appears in diff-pairs
Section titled “Appears in diff-pairs”- question-and-answer vs procedural (varies style)