Frequently Asked Questions
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”how-to-tutorial: 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.
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”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.