FAQ
A list of anticipated questions with direct, self-contained answers, ordered by how often they are asked.
A FAQ collects the questions a reader is most likely to ask and answers each one directly, ordered by frequency or by the reader journey. It optimizes for a reader who arrives with a specific question and wants a fast, self-contained answer, not a narrative. Each entry stands alone: a reader should never have to read the whole thing to get their one answer.
The shape of a FAQ reflects an understanding of the audience: the questions listed are the ones the audience has already demonstrated, not the ones the author wishes they would ask. Each answer should be the minimum necessary to satisfy the question. FAQ ordering is not alphabetical and not by author preference - it is a deliberate editorial decision about the reader, ordered by how often they ask or by the sequence of their journey.
Canonical template
Section titled “Canonical template”## Frequently Asked Questions
### [Most frequently asked question, phrased as the reader would ask it?]
[Answer in 1 to 3 sentences. Self-contained. Do not reference other answers.]
### [Second most frequent question?]
[Answer. If the answer depends on a condition, state the condition first, then the answer for each case.]
### [Third question, often one that surfaces a common misconception?]
[Answer. Correct the misconception directly, then give the right answer.]
### [Next question...]
[Answer...]When to use
Section titled “When to use”A product, service, or process generates a predictable set of recurring questions from users or customers, a landing page or onboarding flow needs to pre-empt common questions before the reader reaches a support channel, a policy or process document needs a companion that handles reader questions without bloating the main doc, support documentation where readers arrive with a specific question and need a fast targeted answer, after a product update, policy shift, or launch that will generate a burst of similar questions.
When not to use
Section titled “When not to use”When the content is a precise technical specification with syntax, parameter definitions, or code examples - use a technical reference instead. When no genuine set of recurring questions exists and the format would organize general information that belongs in a guide or reference. When the topic is complex enough that each question requires extensive context to answer accurately - a guide or tutorial serves that reader better.
Pairs well with
Section titled “Pairs well with”technical-writer, friendly-mentor, instructional, matter-of-fact, question-and-answer
Often confused with
Section titled “Often confused with”technical-reference: Both formats serve a reader who arrives with a specific lookup rather than reading straight through. The difference is content: a FAQ collects recurring natural-language questions with self-contained prose answers, ordered by reader frequency; a technical-reference is a precise specification of syntax, signatures, parameters, fields, and code examples. A FAQ answers “How do I…” or “What happens if…”; a technical-reference documents exactly how something is defined.
- Questions written in the reader’s own words, often starting with “How do I”, “What is”, “Can I”, or “Why does”
- Each question-answer pair is a complete, self-contained unit readable without the others
- Ordered by frequency with the most common question first, or by reader journey stage
- Answers are brief by design - typically one to three short paragraphs - and link out rather than elaborate inline
- No transitional prose between pairs; the pairs stand in parallel, not in sequence
- The question is phrased as the reader would ask it, not as the author would label the topic
Anti-patterns
Section titled “Anti-patterns”- Phrasing questions the way the author thinks about the topic rather than the way the reader asks - A reader searching for help with a forgotten password will not find a section titled “Account credential management procedures”; the question must match the reader’s own phrasing.
- Expanding answers into multi-paragraph tutorials that require the reader to read through to reach the point - Self-containment and brevity are the format’s only advantages over a narrative doc; long answers erase both and signal the content belongs in a guide, not a FAQ.
- Using a FAQ to house precise technical specifications - syntax tables, parameter lists, field definitions, code examples - rather than natural-language question-answer pairs - A FAQ collects recurring natural-language questions with self-contained prose answers; a technical-reference is a precise specification of syntax, signatures, parameters, fields, and code. Blurring the two produces a document that does neither job well.
- Ordering questions alphabetically or by an author-chosen grouping instead of by reader frequency or journey - FAQ ordering is an editorial decision about the reader, not the author; author-centric ordering buries the most common question where readers stop looking.
Failure modes
Section titled “Failure modes”- Over-atomizes - the format tips into a list of one-sentence stubs where every question gets a non-answer too brief to satisfy anything - Each answer must do actual work; if the answer is shorter than the question, the question is probably out of scope for a FAQ, or needs one more sentence of genuine substance.
- Over-populates - the format tips into an exhaustive catalogue of every possible question, including rare edge cases, until the common questions are buried in volume - Audit by frequency; remove questions that only a small fraction of readers will ask and move edge-case depth to linked reference material rather than expanding the FAQ itself.
- Over-isolates - each answer restates so much background context to be self-contained that answers balloon into repeated mini-essays and the document becomes bloated - Self-contained means the reader does not need to read other answers to get their answer, not that each answer must recap the whole product; shared context belongs in a brief preamble, not repeated in every entry.
Instruction
Section titled “Instruction”Write as a FAQ (Frequently Asked Questions). Structure the content as a series of discretequestion-answer pairs. Phrase each question the way the reader would actually ask it, not theway you would label the topic. Each answer must be self-contained: the reader jumping directlyto that pair should get a complete, useful response without needing to read other pairs. Orderpairs by frequency (most common first) or by reader journey stage (orientation beforetroubleshooting). Keep individual answers brief - one to three short paragraphs - and link todeeper resources rather than elaborating inline. Do not write transitional prose between pairs.If an answer requires extensive length to be accurate, the question probably belongs in a guide,not a FAQ.Template
Section titled “Template”See the FAQ template.
Related
Section titled “Related”Pairs well with
Section titled “Pairs well with”Technical Writer, Friendly Mentor, Instructional, Matter of Fact, Question and Answer
Avoid with
Section titled “Avoid with”Confessional, Columnist, Reverent
Often confused with
Section titled “Often confused with”Examples
Section titled “Examples”- Whether the team should move to async-first standups
- Designing a sustainable morning routine
- Choosing Postgres vs DynamoDB for a new service
- Telling stakeholders a committed feature is being cut this quarter
- Getting a new engineer productive in their first two weeks
- Writing to thank a mentor who shaped your career
- Reflecting on keeping a discipline of rest
- Marking a long-serving colleague's departure
- Marking the team shipping a hard, long project
- Arguing a public position on return-to-office
- Announcing a new product to an outside audience
- A personal year-end reckoning with a difficult year
Frequently Asked Questions - Async Standup
Section titled “Frequently Asked Questions - Async Standup”Is the 9am Pacific standup still happening?
Section titled “Is the 9am Pacific standup still happening?”No. The synchronous daily standup is replaced with an async update posted to #team-standup. There is no call to join. The old calendar invite has been removed.
When do I need to post my update?
Section titled “When do I need to post my update?”By 10am your local time, every weekday. That is 10am Pacific, 10am Eastern, 10am UK, or 10am IST depending on where you are. Posting at the start of your morning helps the on-call engineer triage the channel before their midday.
What do I put in the post?
Section titled “What do I put in the post?”Use the three-field template pinned in #team-standup:
- Shipped: what completed in the last 24 hours
- In progress: your current focus
- Blocked or at risk: anything that needs attention, with an @mention of the person who can resolve it
Keep the whole post to under 60 seconds of reading time. If a field is empty, write “nothing today.”
What if I’m blocked and need help right now?
Section titled “What if I’m blocked and need help right now?”Add your blocker to the “Blocked or at risk” field and @mention the person who can resolve it directly in your standup post. The on-call engineer scans #team-standup once between 10am and 11am Pacific and makes sure every @mention has a response before end of the workday. If the situation is urgent, DM or post in #team-dev directly - the async standup does not replace direct communication for critical blocks.
Why are we switching to this format?
Section titled “Why are we switching to this format?”The 9am Pacific standup was 9:30pm for engineers based in India, and Q1 attendance data showed the gap: India-based engineers averaged 3.2 appearances per week versus 4.6 for US-based engineers. Beyond the timezone problem, the 14-minute meeting was producing roughly 4 minutes of information that changed anyone’s behavior, and none of it persisted after the call. Three times last quarter an engineer spent an hour on a problem already solved in a previous standup because there was no searchable record. The async format lets everyone participate at a time that fits their day and creates a record that survives the call.
What happened to the 9am slot on my calendar?
Section titled “What happened to the 9am slot on my calendar?”The time that was five standup sessions per week is now one Thursday working session, 60 minutes, at 8am Pacific (8:30pm IST). Agenda lives in docs/thursday-agenda.md. The session is reserved for topics that genuinely require real-time conversation. If the agenda is empty by Wednesday at 5pm Pacific, we cancel.
Who makes sure blocked items don’t fall through?
Section titled “Who makes sure blocked items don’t fall through?”The on-call engineer is responsible for scanning #team-standup once between 10am and 11am Pacific each weekday. Their job is to confirm every @mention has a response before end of day - not to summarize the channel for everyone else. This on-call reading responsibility replaces the meeting facilitation duty that was on the same rotation.
What if I forget to post one day?
Section titled “What if I forget to post one day?”Post when you remember. A late post is better than no post. If you miss a day entirely, there is no correction needed - just resume the next morning. Chronic gaps hurt the channel’s value for everyone, but a single missed day is not an incident.
Is this permanent or are we still deciding?
Section titled “Is this permanent or are we still deciding?”This is a 30-day trial. The retro document is docs/trial-retro.md. If you have feedback mid-trial, add it there rather than in DMs or side conversations. The decision to keep, adjust, or revert will be made at the Day 30 retro with input from the full team.
Frequently Asked Questions
Section titled “Frequently Asked Questions”What is the four-step routine, exactly?
Section titled “What is the four-step routine, exactly?”Four steps, in order, every weekday morning: water (500ml within 5 minutes of waking), light (10 minutes outside or by a window), movement (15 minutes - walk, stretch, or bodyweight), and planning (10 minutes with paper and pen, top three for the day). The phone stays in the kitchen until step 4 is done. Total time is about 45 minutes; the remaining 15 minutes before family obligations start are buffer for getting dressed and making coffee.
Why does the phone have to stay in the kitchen?
Section titled “Why does the phone have to stay in the kitchen?”The phone-in-the-kitchen rule is the single highest-leverage part of the protocol. Removing the device eliminates the decision entirely - I do not have to resist checking Slack because the phone is not within reach. Before the protocol, I was scrolling email and news for 45 minutes before my feet hit the floor. The kitchen rule turned out to be easier to hold than I expected: 28 of the first 30 mornings, it stayed there.
How do I adapt this to a different wake time?
Section titled “How do I adapt this to a different wake time?”The protocol does not depend on 6:30am - that is when my family obligations (breakfast, school dropoff) require me to transition out of the first hour. What matters is the duration: a solid, uninterrupted hour before those obligations begin. Find the time your own commitments start, count back 60 minutes, and that is your target wake. If 60 minutes is not available, the protocol can run on 45 by trimming movement to 10 minutes and planning to 5.
What do I do if I miss a morning?
Section titled “What do I do if I miss a morning?”Resume the next morning without making it a bigger deal. The tracking log gets an honest “no” in the completed column; I note what happened in one word (travel, sick, drift) and move on. Missed days are information, not failure. The pattern matters more than any single morning: three misses in a week is a signal to look at what is competing with the routine, not a reason to restart a 30-day counter.
Does indoor light count for the light step?
Section titled “Does indoor light count for the light step?”Outdoor light is the target because the intensity difference between even a cloudy morning outside and indoor lighting is significant. That said, standing by the largest open window is the backup when going outside is not realistic - bad weather, early travel, a sleeping household. A screen (phone, laptop, TV) does not count as light regardless of brightness settings.
Why paper for planning instead of an app?
Section titled “Why paper for planning instead of an app?”Two reasons from experience: apps pull me into notification territory before the phone-free hour is finished, and screens in the planning step erase the cognitive separation the rest of the routine is trying to build. Writing three priorities by hand takes about 5 minutes and has closed more days satisfied than any digital tool I have used. If you prefer a digital planning tool, use it after step 4 when the phone is already in hand - but try paper for the first two weeks before deciding.
What is the travel variant for when I am away from home?
Section titled “What is the travel variant for when I am away from home?”There is not a stable one yet. In month 1, two of three travel days ended in a skipped morning because I tried to adapt the full protocol to a hotel context and abandoned it halfway. Month 2 includes writing an explicit travel variant - most likely water and planning only, with light and movement logged as skipped rather than failed. A routine that contracts gracefully beats one that collapses entirely.
Frequently Asked Questions: Notification Service Datastore (ADR-0023)
Section titled “Frequently Asked Questions: Notification Service Datastore (ADR-0023)”Why did we choose Postgres instead of DynamoDB?
Section titled “Why did we choose Postgres instead of DynamoDB?”The decision came down to operational capacity. We have a 4-person on-call rotation and adding a second datastore means a second runbook, a second monitoring surface, and a second debugging skillset on every page. The architecture meeting on Wednesday concluded that this cost outweighed DynamoDB’s access-pattern advantage at launch scale (500K events/day). ADR-0023 records the full reasoning.
Doesn’t DynamoDB actually fit the notification access pattern better?
Section titled “Doesn’t DynamoDB actually fit the notification access pattern better?”Yes - and Marcus’s argument holds in isolation. The notification workload is write-heavy with point-lookups by user, which DynamoDB handles natively. We accepted the worse access-pattern fit in exchange for a better fit for the team’s operational reality and for the certain launch scenario rather than the uncertain 10x growth scenario that depends on a deal that has not yet closed.
What does the Postgres setup actually look like?
Section titled “What does the Postgres setup actually look like?”A new notifications schema in the existing primary cluster, a pg_notify-backed job queue, and a notification_jobs table. Read replicas absorb fanout reads. The service sits entirely within the existing operational footprint - no new cluster, no new backup story, no new monitoring surface for on-call.
How do cross-database queries work?
Section titled “How do cross-database queries work?”They stay as standard SQL joins. Because the notifications schema lives in the same primary cluster as the existing monolith data, joining notifications to users, accounts, and workspaces requires no cross-service lookup or API call. This was a secondary argument for Postgres that would not hold with DynamoDB.
What’s the plan when we outgrow Postgres?
Section titled “What’s the plan when we outgrow Postgres?”ADR-0023 defines a revisit threshold of 5M events/day sustained. When write rate crosses that level, the team evaluates DynamoDB migration before scaling the Postgres path further. Jordan adds queue depth and write rate to the on-call dashboard by 2026-05-22 so the team tracks the approach to that threshold continuously.
What if the Slack-partnership deal closes and growth arrives ahead of schedule?
Section titled “What if the Slack-partnership deal closes and growth arrives ahead of schedule?”This is a known, low-severity risk. Priya tracks deal timing in the partnership review cadence and gives the team 30 days of warning before volume impact arrives. That triggers the 5M events/day revisit early, not as an emergency. Both Postgres and DynamoDB carry an estimated 3-6 week rework window if a migration is needed, so neither choice is a trap.
Who owns the decision going forward?
Section titled “Who owns the decision going forward?”Ana owns the Postgres partitioning work scheduled for Q4 if growth tracks projection. Jordan owns the on-call dashboard threshold metric. Priya holds the ADR-0023 record and the sprint planning commitment from Friday. For questions about the decision rationale, see ADR-0023 or reach Ana directly.
Frequently Asked Questions: Insights Dashboard
Section titled “Frequently Asked Questions: Insights Dashboard”Why is the Insights dashboard not shipping in Q3?
Section titled “Why is the Insights dashboard not shipping in Q3?”The billing-system migration expanded past its original estimate and consumed the engineering capacity that had been allocated to Insights. The two workstreams could not run in parallel without putting both at risk. Shipping on the original date would have meant releasing the dashboard without saved-view persistence and scheduled-report delivery - the two capabilities the committed accounts specifically asked for.
When will the Insights dashboard ship?
Section titled “When will the Insights dashboard ship?”The dashboard is targeted for Q1 2027, with a planned release date of March 13, 2027. This target is confirmed for Q4 planning but not yet in customer-facing communications; leadership sign-off is needed before that date is shared in writing with accounts.
What can I use right now?
Section titled “What can I use right now?”A CSV export of the same underlying Insights data ships September 26. Access it from Settings > Data and Analytics > Export > Download CSV. The export covers all usage events from your account creation date through the end of the previous calendar day. Open the file in any spreadsheet or BI tool to filter by date range, group by user or feature, and build the views you need.
What is in the CSV export?
Section titled “What is in the CSV export?”Each row is one event. Columns include: the user who triggered the event, the action recorded, a UTC timestamp in ISO 8601 format, the session ID that groups related events, and the account plan tier at the time. The export does not include saved views, scheduled report delivery, or in-app visualizations - those are part of the Q1 dashboard scope.
Will the Q1 date actually hold?
Section titled “Will the Q1 date actually hold?”The Q1 2027 target is backed by a locked engineering scope and a specific delivery date (March 13, 2027). The one named risk is another mandatory infrastructure workstream appearing before then; nothing of that kind is currently scoped. The team will surface any threat to that date early rather than letting it emerge close to delivery.
Who do I contact with questions?
Section titled “Who do I contact with questions?”For questions about the export format or the Q1 timeline, contact insights@meridian.io. For the four key accounts that were given the original Q3 commitment, direct concerns to Jordan Park (customer success), who is coordinating outreach and individual calls this week.
Frequently Asked Questions - New Engineer Onboarding
Section titled “Frequently Asked Questions - New Engineer Onboarding”What should I do on day one?
Section titled “What should I do on day one?”Work through the access checklist with your buddy. It covers source control org membership, VPN and SSO setup, CI/CD access, the observability platform, on-call viewer, secret manager, and the four core chat channels. Do not move on until every item is verified - the bootstrap script will tell you exactly what is still missing. Your buddy owns the checklist with you; nothing on it is expected to be self-solved.
How do I get my local environment running?
Section titled “How do I get my local environment running?”Clone the services repo and run ./scripts/bootstrap.sh. The script installs local tooling, sets environment variables, and runs the health check suite. If it exits with an error, read the output before asking a teammate - it prints exactly what is missing. When make smoke-test passes, your environment is healthy.
What is the goal for week one versus week two?
Section titled “What is the goal for week one versus week two?”Week one is orientation, not output. The three things that matter: trace one real production request from the API gateway to the data store using the observability platform, meet the owners of the services you will touch first, and watch one live deploy with the on-call engineer. Week two flips to output - you implement a scoped first change, write the test, and own the deploy end to end.
Who is my buddy and what do they actually do?
Section titled “Who is my buddy and what do they actually do?”Mei is the onboarding DRI and your point of contact for any gap in the plan. Your peer buddy handles the access checklist with you in days one and two and runs two 90-minute guided walkthroughs in week one - one on service topology and one on deployment and on-call tooling. Notes from those walkthroughs belong to you, not the buddy. In week two, Arjun is paired as a reviewer and available to pair on blockers while you drive your first change.
What does my first real change look like?
Section titled “What does my first real change look like?”The team picks a ticket from the good-first-issue label before your first day. It touches one service and one data model, has a test you can write in under an hour, and does not require on-call context to understand. You drive the implementation and the deploy; your reviewer is there for blockers and the pull request review, not to take over. The goal is that you own the full cycle end to end.
When do I go on call?
Section titled “When do I go on call?”On-call starts at week five. You are excluded from the rotation for your first thirty days. In week one you observe a live deploy and join the on-call handoff call so you know the cadence and the escalation path - that is learning, not responsibility.
What if I am blocked or something is missing from my access?
Section titled “What if I am blocked or something is missing from my access?”Tell your buddy the same day. Access gaps are expected and your buddy is the named owner of resolving them. If a provisioning request is stuck in the infra queue - like a staging environment credential - Mei can escalate through the engineering manager. Do not absorb delays silently; the protocol is designed to catch these, but only if someone surfaces them.
What happens at the end of the two weeks?
Section titled “What happens at the end of the two weeks?”There is a thirty-minute retrospective on the last Friday to close the formal onboarding window and surface anything still open. The retro asks about belonging explicitly - functional progress does not automatically answer that question. The buddy relationship does not end at two weeks; it typically continues as an informal channel. On-call briefings continue into week three and beyond as you build system familiarity.
What You Did for Me - A Ten-Year Retrospective in Questions
Section titled “What You Did for Me - A Ten-Year Retrospective in Questions”For: Dana Forsythe From: Sable Marchetti Written: June 2026
This is addressed to you. The questions below are the ones you might reasonably ask on receiving it. Each answer is complete on its own; you do not have to read them in order.
Frequently Asked Questions
Section titled “Frequently Asked Questions”What are you thanking me for, exactly?
Section titled “What are you thanking me for, exactly?”You put me forward to lead the Alderton platform migration in March 2016. I told you I was not ready. You nominated me anyway, and you were right that I was closer than I knew. That nomination - made before I had the confidence to want the role - is what this is about.
Why does a project from 2016 warrant a thank-you in 2026?
Section titled “Why does a project from 2016 warrant a thank-you in 2026?”Because I did not understand what you had done until I did it myself. In February of this year I nominated Priya Osei to lead the Cassava data-pipeline rebuild, over some internal skepticism. I stayed close while she was stuck, and I sat on my hands when the temptation to take the work back was strongest. The project shipped. While I was drafting Priya’s mid-year review, I realized the shape of her arc was almost exactly the shape of mine in 2016, and I had no explanation for where I learned to do that except you.
Did you know at the time what it would cost you?
Section titled “Did you know at the time what it would cost you?”Probably not in full. The six months you spent following my lead rather than exercising yours did not appear on any delivery plan. The questions I brought you when I got stuck cost you time you did not have. You absorbed the reputational exposure for the duration - if the Alderton migration had failed, what the organization would have remembered is that you vouched for someone who was not ready, not that I was the one who was not ready. I did not understand any of that at the time. I understand it now because I have been on your side of the equation.
What did you actually do during those six months?
Section titled “What did you actually do during those six months?”You stayed visible without substituting your judgment for mine. You came to the first two stakeholder meetings and said almost nothing. When I got something wrong in the third one, you corrected me afterward, not during. You redirected my thinking without replacing it. You did not accept the work back when I offered it to you in a moment of genuine panic. That last part was the hardest thing you did, and it was also what taught me the most.
How did it go?
Section titled “How did it go?”The migration shipped. I led the post-mortem. By April 2017 I had an enterprise-scale delivery on my record and a durable belief that I could lead something I had not done before. That belief has compounded for ten years. The most lasting thing you built in me was not a skill but a pattern: the expectation that real stakes are where real development happens, not simulated ones.
Why are you writing this now instead of then?
Section titled “Why are you writing this now instead of then?”Because I could not have written it accurately then. At the time I was grateful in a general way but could not have described the shape of what you did or articulated what it made possible. It took Priya’s project, and finding myself doing what you did, to see it clearly enough to write down. This is the first moment I could have sent this and had it be true in full rather than in approximation.
What do you need from me?
Section titled “What do you need from me?”Nothing. No action required, no reply expected, though I would be glad to hear from you. What I needed was to put this in writing before another decade passed and you had only my silence to infer from.
Frequently Asked Questions
Section titled “Frequently Asked Questions”What does a rest day actually look like?
Section titled “What does a rest day actually look like?”One full day each week - one in seven - with no work output, no task completion, and no checking of messages or notifications. Not a lighter workday. A structurally different kind of day. The rule is about what I will not do, not what I must do instead: sleep without an alarm if that happens, eat without a screen, spend time with something that has no output to report. The first rest day will not feel like rest. That is expected.
I feel anxious when I stop. Is something wrong?
Section titled “I feel anxious when I stop. Is something wrong?”No. The anxiety is a normal response to setting down the monitoring habit. A large part of what feels like “staying on top of things” is low-level scanning - watching the inbox, tracking the queue, keeping a background count of what is incoming. Resting means setting that down, and setting it down feels like risk before it feels like relief. At week 14 of this practice, the anxiety at the start of a rest day has not fully disappeared. It has changed - it arrives faster and leaves faster. Give it the first hour rather than fighting it.
What if I have tried this before and it collapsed?
Section titled “What if I have tried this before and it collapsed?”That is the common case. The first version of this practice ran six weeks before a deadline ended it. There was then an eleven-month gap before restarting. The restart did not require conditions to be different. It required restarting. The question to ask is not “when will things settle down enough to try again?” but “what is the smallest version I can actually protect right now?” In the early weeks of the current run, the phone-away window was four hours. It is now ten. The practice does not have to be complete to be real.
What counts as rest?
Section titled “What counts as rest?”The test is not silence or stillness - it is whether the activity requires output or sustained monitoring of work. A walk, a meal, reading something unrelated to work, time with other people: these count. Passively scrolling through notifications does not count, even if it feels low-effort. The harder edge case is creative or intellectually engaging activity that is not technically work. A rough guide: if you would feel the need to save the result or report on it, it is probably not rest.
What happens when I break the practice?
Section titled “What happens when I break the practice?”The field notes from this run include weeks where the practice broke. Both times the pull was the same: something unresolved was waiting, and the cost of leaving it alone for a day felt larger than the cost of just handling it. It was not larger. The break did not resolve the underlying situation. The next rest day still came the following week. Missing a week is not a reason to restart the count or revise the decision. It is data about which situations are hardest to hold the boundary against.
How will I know if it is working?
Section titled “How will I know if it is working?”The most direct evidence tends to come on Monday. The current run has produced several weeks where problems that had been circling for days resolved more cleanly after the rest day. A less direct sign is whether the background productivity-accounting habit - the process that tallies whether the rest was “worth it” while you are still in the middle of it - starts to arrive later or leave sooner. That habit does not disappear fast. It is named here as the active risk in the practice, not a side note. But a gradual shift in its timing is evidence the practice is taking hold.
Frequently Asked Questions - Howard Thayer’s Retirement
Section titled “Frequently Asked Questions - Howard Thayer’s Retirement”Howard Thayer’s final day at Crestfield Group is June 27, 2026, completing twenty-six years of service. This FAQ covers the most common questions about continuity, documented knowledge, and what comes next.
When exactly does Howard leave, and what has already transferred?
Section titled “When exactly does Howard leave, and what has already transferred?”Howard’s last day is June 27, 2026. System access and vendor credentials transferred to three named successors by June 20 - no hard dependencies on Howard’s accounts remain in operational systems.
Who do I contact now for the things I used to ask Howard?
Section titled “Who do I contact now for the things I used to ask Howard?”Operational coordination questions go to Carolyn Marsh, Operations Lead. For incident-response and vendor escalation, the runbook Dana Reyes and Marcus Okonkwo compiled is the starting point; Dana Reyes is the named owner for incident continuity through Q3.
Is Howard’s institutional knowledge documented somewhere I can find it?
Section titled “Is Howard’s institutional knowledge documented somewhere I can find it?”Partially. Howard worked with Dana Reyes and Marcus Okonkwo in two sessions in May and June to document his informal decision trees, vendor escalation paths, and four utility contacts that had never been in the official system. That runbook covers the procedural layer. His judgment in genuinely novel situations was not something two sessions could transfer, and that gap is named honestly as a standing risk rather than closed.
Was there a send-off and can I see it if I missed it?
Section titled “Was there a send-off and can I see it if I missed it?”Yes. An all-hands was held June 25, attended by forty people in-person and eighteen remote. The session was recorded for the regional site that could not send a representative. Howard spoke for four minutes. He said he was proud of the team and that he did not want to be the reason anyone felt stuck.
Howard showed me something that never made it into any runbook. Should I pass it on?
Section titled “Howard showed me something that never made it into any runbook. Should I pass it on?”Yes, and soon. The runbook is a living document. Send vendor contacts, informal practices, or institutional workarounds Howard taught you to Carolyn Marsh at cmarsh@crestfieldgroup.internal by July 11.
Who covers the mentoring Howard did informally?
Section titled “Who covers the mentoring Howard did informally?”No single person is taking that role. Two senior individual contributors have taken on mentoring as an explicit expectation. If you were mentored by Howard and want support, reach out to your manager or to Carolyn Marsh. If you manage someone Howard mentored, plan a direct check-in in July and August - the absence tends to become real six to eight weeks after the goodbye.
Project Halyard: Frequently Asked Questions
Section titled “Project Halyard: Frequently Asked Questions”What is Project Halyard and what did it actually ship?
Section titled “What is Project Halyard and what did it actually ship?”Project Halyard rebuilt the company’s checkout pipeline from scratch and replaced the legacy system entirely. The new checkout handles all sessions as of June 13, 2026. The legacy flow moved to a 31-day read-only archive on cutover day and is scheduled for full decommission on July 14.
Why did this take 14 months?
Section titled “Why did this take 14 months?”The project ran the new and old checkout systems in parallel the entire time - no single hard cutover, no forced migration window. That approach added operational overhead but it also made two separate near-misses recoverable without any customer-facing incident. The timeline slipped twice: a cart-state mismatch found in February pushed the March launch to April, and a race condition found in April pushed the May window by eleven days. Both delays were the right call, and the June 13 launch was clean because of them.
What were the two near-misses I have been hearing about?
Section titled “What were the two near-misses I have been hearing about?”The first happened in February. Marcus Teel caught a silent cart-state mismatch in staging that would have corrupted multi-item orders under split payment. The second happened in April. Jordan Osei identified a race condition between the payment processor callback and the session store during the final dress rehearsal. Neither was caught by the automated test suite alone. Both were found by engineers reading the data carefully enough to notice something was wrong.
Did the cutover affect my integration?
Section titled “Did the cutover affect my integration?”The v2 pipeline is backward-compatible with existing cart identifiers, so v1 cart IDs continued to work after June 13. If you were still calling v1 endpoints at cutover, your sessions were migrated automatically. The migration guide at docs/migration-v1-to-v2.md covers known edge cases. If you are seeing unexpected behavior, open an issue in the checkout-reflow repository or find the team in the engineering channel.
When will I see the cart abandonment numbers improve in the data?
Section titled “When will I see the cart abandonment numbers improve in the data?”The first clean post-launch baseline is expected July 7. Clean attribution requires 21 days of post-cutover data. Both checkout flows ran simultaneously for the final four months of the project, which will create noise in earlier numbers. The analytics team is annotating those overlap periods in the report. Do not read the June numbers as a reliable signal; wait for Mia Chen’s annotated baseline before drawing conclusions.
Can we roll back to the old checkout if something goes wrong?
Section titled “Can we roll back to the old checkout if something goes wrong?”No. The legacy checkout moved to read-only archive on June 13 and is on track for full decommission on July 14. The window for a routine v1 rollback has closed. If a critical issue surfaces before July 14, escalate immediately to the engineering channel - there may be a narrow recovery path - but rolling back is not a standard option at this point.
Who should I contact for follow-up questions?
Section titled “Who should I contact for follow-up questions?”For technical questions about the new checkout pipeline, open an issue in the checkout-reflow repository. For the decommission timeline and operational runbook questions, Dani Rowe is the right contact. For the cart abandonment baseline and attribution questions, reach Mia Chen on the analytics team. The full project history, both near-miss post-mortems, and documentation of the two slip decisions are in the project archive.
Frequently Asked Questions - Work Location Policy
Section titled “Frequently Asked Questions - Work Location Policy”What is the new work location policy?
Section titled “What is the new work location policy?”All employees except those hired into explicitly remote-eligible roles are expected to work in the office on two designated anchor days per week: Tuesday and Thursday. The remaining three working days are fully flexible - each employee decides individually whether to work at home or in the office. The effective date will be confirmed after executive sign-off, currently targeted for the week of June 28.
Which days are the anchor days, and what does “anchor day” mean?
Section titled “Which days are the anchor days, and what does “anchor day” mean?”Tuesday and Thursday. An anchor day is a mandatory shared presence day, not a preference day. If your role is not designated remote-eligible, your manager expects you in the office on both days unless you have a documented exception approved by your manager and the People team. Anchor days are the structural commitment the policy is built around; the flexibility on all other days depends on those two days holding.
Does this apply to me if I was hired as a remote employee?
Section titled “Does this apply to me if I was hired as a remote employee?”No. Employees hired into roles explicitly designated as remote-eligible are excluded from the anchor-day requirement. Your offer letter or role definition will specify whether your position carries that designation. If you are unsure, ask your manager or contact the People team directly.
What if I have a conflict on a Tuesday or Thursday - travel, a medical appointment, a family obligation?
Section titled “What if I have a conflict on a Tuesday or Thursday - travel, a medical appointment, a family obligation?”Occasional conflicts are handled as exceptions. Talk to your manager. The policy is designed to be durable over a full quarter, not inflexible against every individual circumstance. One-off accommodations for genuine conflicts do not undermine the structure. The failure mode the policy is guarding against is quiet drift - anchor days eroding week by week until they are no longer anchor days in practice.
What about accommodation requests related to disability, caregiving, or other ongoing needs?
Section titled “What about accommodation requests related to disability, caregiving, or other ongoing needs?”Ongoing accommodation requests follow the same process as any other workplace accommodation, handled by the People team. The anchor-day policy does not override the organization’s existing accommodation obligations. If regular Tuesday or Thursday in-office work creates ongoing difficulty, contact the People team before the policy takes effect rather than waiting.
I live outside commuting distance and my role is not listed as remote-eligible. What happens?
Section titled “I live outside commuting distance and my role is not listed as remote-eligible. What happens?”This is a conversation to have with your manager and the People team promptly. The policy is not retroactively reclassifying roles. If your situation - living outside reasonable commuting distance - was known and accepted at hire, that context matters. Do not wait until the policy takes effect to clarify how your situation is categorized.
Why not just let everyone choose which days to come in?
Section titled “Why not just let everyone choose which days to come in?”Self-selected attendance does not reliably produce the shared overlap the policy is designed to create. When anchor days are individual preferences rather than shared commitments, people who already prefer the office come in and people who prefer remote stay home - and the two groups rarely share a floor. Trust accrues faster in the same room, and new hires orient faster when they can catch colleagues between meetings. Both of those outcomes require predictable shared time, not optional attendance that happens to coincide.
The policy is not a split-the-difference compromise between office-first and fully-remote positions. It is a deliberate structure: two protected days for the collaboration that benefits from physical proximity, and three genuinely flexible days for the focused and personal-schedule work that does not.
When will the effective date be confirmed?
Section titled “When will the effective date be confirmed?”After the executive sponsor briefing scheduled for June 28. The People team and your manager will communicate the exact start date before it arrives. Until then, existing arrangements remain in place.
Frequently Asked Questions
Section titled “Frequently Asked Questions”What does Tidemark actually do?
Section titled “What does Tidemark actually do?”Tidemark connects to the places your team already stores customer feedback - support ticket trackers, chat exports, spreadsheets - and produces a single ranked, shareable roadmap view. It identifies recurring themes across your sources, scores them by how often they appear and how recent they are, and gives your whole team a shared picture of what customers are asking for. The process that used to mean someone manually reading everything and copying it into a spreadsheet takes minutes instead of days.
Is this built for teams like mine?
Section titled “Is this built for teams like mine?”Tidemark is for product teams of two to twenty people who own the roadmap but do not have a dedicated research operation. If your team is currently consolidating feedback by hand - reading scattered sources, copying items somewhere central, and then debating priority in a meeting - that is the exact workflow Tidemark replaces.
How do I sign up or try it?
Section titled “How do I sign up or try it?”The waitlist is open at tidemark.io. People who signed up before June 30 get same-day access. New sign-ups join a rolling queue. If you would rather see the product before committing, there is a booking link on the same page for a 20-minute product walk with a member of the team. It is not a sales call - just the product.
What does Tidemark cost?
Section titled “What does Tidemark cost?”Three plans: a free solo plan for individuals (no trial period required), a $29/month team plan for up to 15 seats, and a custom plan for organizations that need SSO and audit logs. During the first 90 days after launch, the free plan carries no cap on feedback volume.
What feedback sources does Tidemark connect to?
Section titled “What feedback sources does Tidemark connect to?”Tidemark reads from the feedback sources your team already uses. If your feedback lives in a spreadsheet, a chat thread export, or a support ticket tracker, Tidemark can pull from it without requiring you to migrate or reformat anything. The full list of supported sources is at Connecting feedback sources.
How does Tidemark decide what ranks highest?
Section titled “How does Tidemark decide what ranks highest?”Tidemark scores each feedback theme by two factors: frequency (how many times the theme appears across your sources) and recency (how recent the mentions are). The ranked output is meant as a starting point for your team, not a final answer. Collaborators you invite can re-rank items once the initial pass is complete. The full scoring logic is at How ranking works.
What does the shared roadmap view look like?
Section titled “What does the shared roadmap view look like?”After Tidemark processes your feedback, you receive a link to a read-only view of the ranked themes. Recipients do not need a Tidemark account to view it. Collaborators you grant access can leave comments or re-rank items. See Sharing and permissions for details on access levels.
Who can I contact with questions?
Section titled “Who can I contact with questions?”Email launch@tidemark.io for press inquiries or product questions. You can also book a 20-minute walkthrough at tidemark.io if you prefer to ask questions live before signing up.
Frequently Asked Questions
Section titled “Frequently Asked Questions”What happened this year?
Section titled “What happened this year?”Two things failed. In March, the Meridian initiative - a community broadband project I had led for eighteen months - was dissolved when the primary funder withdrew. The infrastructure proposal was sound; the coalition held; the funding did not. In the months that followed, a six-year friendship with Celeste changed shape in ways neither of us fully chose and that have not reversed. Those are the events. They are not the whole story, but they are the structure of it.
What happened to Meridian?
Section titled “What happened to Meridian?”The primary funder withdrew in March and the initiative could not continue without them. Eleven people had given significant time to the project. No deployment happened. No continuation was found. I have not yet written a retrospective for the coalition, and that absence is unfinished work, not a closed chapter.
What did I get wrong?
Section titled “What did I get wrong?”Two things I can name clearly. With Meridian, I conflated momentum with progress. I kept the coalition aligned around optimism when some members needed a harder truth earlier - I was protecting the project by managing perception, and what I was actually doing was delaying a reckoning that arrived anyway, with less trust intact.
With Celeste, I kept too much of what I was going through to myself. I told myself that was independence. It read as distance, and by the time the distance was undeniable, there was not much left to close it.
What happened with Celeste?
Section titled “What happened with Celeste?”Celeste and I had been close for six years. After the Meridian closure the relationship began to change - slowly at first, and then quickly. By June it was clear we were not going to stay in close contact. We have not spoken since August. I do not know whether repair is available, and I am not pretending I have a plan for it. This is unresolved because I have not decided what I want to do, not because the path is unclear.
Why have I not answered Theo’s message?
Section titled “Why have I not answered Theo’s message?”Theo sent a message in April. I read it and did not respond. The honest reason is that answering it requires acknowledging something I had been avoiding, and the longer I waited, the harder the acknowledgment became. That cycle is not a reason to keep waiting. Answering Theo is the first named action going forward.
What am I carrying forward?
Section titled “What am I carrying forward?”The commitment to full investment, and the obligation to be honest when things are not working. What the year showed is that deep investment is costly when it does not pay off, and that I sometimes protect the story of the work at the expense of the people in it. That is the thing to change, not the depth of the commitment.