Morgan Chen

Quick Mercury sync note: Oakland BART delay meant I joined Devon from the train and missed the first few minutes where they were arguing through which QA items were actually release-blocking. Devon sent the blocker list after, so I’m caught up now.

Please break this Evergreen bundle into three buckets before Priya’s review: product-copy issues, support triage items, and procurement-language questions. Keep it usable for Priya/Jake/Sarah rather than turning it into a customer response. From: Sarah Kim To: Morgan Chen, Priya, Jake, Devon Hayes Date: Mon, Apr 1, 2024 Subject: Evergreen admin testing bundle — support + design + procurement Morgan / Priya / Jake / Devon — Pulling today’s Evergreen admin-testing feedback into one bundle before Priya’s next review. Nothing here asks for timing; it is mostly language / role clarity, plus procurement objections to wording that sounds more committed than the current product state. 1) Support capture — pending invites / resend Screenshot 1 - Page: Admin settings > Members > Pending invites - Banner: "Invite sent to avery@evergreen.example" - Secondary text: "They will join this workspace when they accept" - Evergreen annotation: "Does this mean the user can act in Treasury Ops, or only that the invite exists?" Screenshot 2 - View: invited member detail drawer after resend - Status: "Pending" - Action visible: "Resend invite" - Evergreen annotation: "We do not know who is allowed to resend this or whether resending changes the approval trail." 2) Figma comments on Priya’s admin/member states Priya empty-state mock text - "No members yet. Invite teammates when you are ready to collaborate." Evergreen note on the empty state - "The mock helps explain why the list is empty, but it still does not explain which role can resend an invite when the original recipient says they never got it." Comment E1 — SSO label - Current label in mock: "SSO required" - Evergreen comment: "'SSO required' sounds like the bank policy is complete here; prefer wording that says enforcement is configured by the workspace admin." Comment E2 — audit label - Current label in mock: "Audit log" - Companion action in mock: "Export audit log" - Evergreen comment: "'Audit log' is understandable, but 'Export audit log' made legal ask whether this is a contractual reporting feature." 3) Procurement wording objections a) "Enterprise-ready admin controls" - Evergreen objection: reads like a production commitment across all enterprise accounts. b) "Compliance-friendly auditability" - Evergreen objection: sounds like a compliance claim rather than product discovery. 4) My read - The repeated question is not whether the UI says an invite exists; it is what authority or state that implies, who can resend, and whether resend/admin changes create any visible trail today. - I have not answered yet. Sending this over so Priya’s review has the exact wording rather than a paraphrase. Sarah

Anna traced the Monday activation dip: Mixpanel was missing a renamed event in one view, while Looker was fine. Not a real usage drop.

HR and Sarah have Nadia’s pre-start logistics checklist moving now — forms, draft first-day Zoom holds, and the reminder that customer-facing work waits until she actually starts.

Kara pulled out the newsletter lines she thinks are too strong. From: Kara <kara@kestrel-test.com> To: Morgan Chen <morgan@atlas-test.com> Cc: Sarah Kim <sarah@atlas-test.com> Date: Mon, Apr 1, 2024 Subject: Mercury newsletter draft — three lines that may be too strong Morgan, Sarah — First newsletter draft is attached, but these are the three passages most likely to sound strong. I can tell they may be too roadmap-y. 1) "This summer Scaffold is bringing enterprise-grade Mercury controls to every team, with SSO, auditability, and admin workflows becoming the backbone of the Q3 roadmap." 2) "Our design partners are already validating the full enterprise procurement story, so customers can expect a clear path from prototype to organization-wide deployment." 3) "Mercury turns scattered support, billing, and admin workflows into a unified launch-ready platform for larger companies that need confidence before they buy." If helpful, I can rewrite just these sections in place rather than reopen the whole piece. Kara Please rewrite just those passages so the draft is still useful, but no broad Q3 enterprise-roadmap commitment, no design-partner proof claim, and no launch-ready platform overreach.

Kibo had a gross little breakfast stomach incident. Jamie got the worst of it while I was between calls, and Kibo was eating normally again by evening.

Blueline moved the repair window from Tuesday morning to Thursday midday, so I had to reshuffle one customer/investor prep block around being home. Annoying, but contained.

Sofia’s post-close Northstar ask is narrower than I expected: two Mercury evidence slides, not a data-room refresh. She wants retention cohorts, Evergreen proof points, and the remaining pricing/package caveat kept visible.

Devon’s rough pass is here. From: Devon Hayes To: Morgan Chen Cc: Anna Martinez, Sarah Kim Date: Tue, Apr 2, 2024 Subject: Rough two-slide Mercury pass for Sofia Morgan — Pasting the rough two-slide pass below before I clean the speaker notes. The content is directionally right, but the Looker chart, Evergreen quote, Acme reference, and package caveat are still fighting each other. Slide 1 Title Mercury evidence: retention and pull signals. Body "Current Mercury cohort retained better than the prior onboarding cohort through week four; Looker view shows strongest repeat activity in teams using admin controls during the first seven days." Chart placeholder "Looker cohort chart: Jan/Feb Mercury users vs prior onboarding flow, week 1 through week 4." Margin note "This chart is defensible, but it reads like we are claiming causality. We are not." Slide 2 Title Customer pull, not roadmap theater. Body "Evergreen is pushing on SSO, auditability, and admin workflows; Acme cares about dashboard confidence and billing-account visibility. These are real buyer questions, but pricing/package remains a caveat." Quote placeholder "Evergreen: admin controls are the first place procurement slows us down." Margin notes - "Quote is useful but too procurement-heavy." - "Acme reference is helpful as customer-pressure language, but next to Evergreen it starts reading like one merged enterprise proof story." - "Pricing/package caveat currently looks like weakness instead of honest boundary-setting." Footer caveat "No broad enterprise SKU commitment in Q3." Open issues for the next pass - The chart can stay if it reads as correlation inside the current Mercury group, not a cause-and-effect claim from admin controls. - The Evergreen quote is useful, but I want it to sound like buyer pull rather than procurement theater. - If Acme stays in, it should remain separate from the Mercury design-partner proof lane. Devon Can you make the two-slide story coherent without sanding off the package caveat or making Acme look like part of the Mercury design-partner wave?

Can you reason through this replay failure? I need the likely path and the evidence that would distinguish a Clerk payload issue from our JWT mapping bug. Auth rewrite replay test — Clerk webhook replay failure Date: 2024-04-02 Replay-test log excerpt 2024-04-02T10:42:17Z clerk.replay event=user.updated replay_id=rep_041 source_user_id=user_7Q9 expected_workspace=wrk_evergreen_ops 2024-04-02T10:42:18Z auth-webhook normalized user_id=user_7Q9 external_id=clerk_user_7Q9 metadata_keys=[email,role,last_login] workspace_claim=<missing> 2024-04-02T10:42:18Z api_v2 jwt.build subject=user_7Q9 aud=graphql-api-v2 workspace=<nil> result=error code=JWT_METADATA_MISMATCH 2024-04-02T10:42:19Z replay assertion failed: expected user_id user_7Q9 present=true; expected workspace claim wrk_evergreen_ops present=false. Test note - Live create path passed yesterday with workspace claim present. - Replay path is the only failing path so far.

Acme billing dashboard thread Apr 2, 2024 — Jake internal note for Acme Dashboard account Acme shows invoice INV-AC-1042 twice in the customer-visible month total. Stripe charge list has one successful charge and no duplicate payment attempt. billing-service received one Stripe invoice.paid webhook; BillingOrchestrator rendered two dashboard rows because the invoice summary job retried after a timeout and did not de-dupe the display cache. I am clearing the duplicate display row and checking whether any other Acme dashboard rows share the same cache key. Customer impact: dashboard number looks high; actual payment/Stripe ledger is single-charge. Forwarded question from Greg Shipman “Our finance lead sees April looking overstated. Are we at risk of a duplicate charge, or is this just the dashboard?” Please draft a customer-safe reply for Greg that acknowledges the dashboard discrepancy clearly but does not imply there was an actual Stripe charge problem.

Priya’s admin empty-state review landed on keeping the calmer copy in the prototype. The more explanatory version is parked for later comparison, not swapped in now.

Pinecone’s API v2 follow-ups are below. Please draft concise technical answers I can use with them — accurate against the current GraphQL/JWT connector guidance, but don’t open up a broader integration commitment. Email Subject: Re: Pinecone connector verification docs wording Date: Tue, Apr 2, 2024 From: Pinecone Hi, Thanks for the clarification on the supported header-only verification path. We have three follow-up questions on the API v2 integration path as we finish our connector-side handling: 1) For paginated GraphQL API v2 queries, are cursors stable if a connector retries the same page after a transient auth failure, or should we restart pagination from the prior successful page? 2) If a JWT expires during a connector retry, should the client refresh credentials and replay the same GraphQL operation, or treat the operation as failed and start a new request? 3) Can workspace-scoped tokens be rotated in place without forcing the customer through a full reconnect? We’re trying to make sure our behavior matches the current quickstart/support guidance rather than relying on older assumptions. Thanks, Pinecone --- Attached internal scope note - Answer from the current API v2 quickstart and supported connector/auth model only. - Quickstart reference: https://docs.atlas-test.com/api/v2/graphql-quickstart - Do not promise a new token-rotation endpoint, SSO/admin expansion, or broader connector-header behavior.

Mom and Maya had the family dinner time crossed up. I clarified it on a quick call before jumping back into work.

Trader Joe’s subbed the one Kibo item Jamie actually needed. Jamie grabbed a backup on the way home, so we avoided another dog-food scramble.

The all-hands ran long and these are my raw notes. Q1 all-hands — Morgan raw notes Date: 2024-04-03 Opening - “Q1 was about making Mercury real enough to learn from, not declaring victory.” - Keep the post-raise line tight: more room, same discipline. Defensible story, not a bigger story. - Need to answer scope questions directly, not with general optimism. Mercury update - Current release focus: admin controls, live-sync reliability, invited-member handoffs, and evidence quality before Q3 launch planning. - Weekly Mercury truth check stays on support edges, live-sync trust, admin friction, and what is materially changing in product. - Enterprise-readiness review stays a separate lane from current Mercury release work; do not contaminate release notes with broader enterprise scope. - Leo’s current platform/seams read: live-sync trust looks stable; overnight warning spikes are watch items unless we reproduce an actual state bug. - Recovered-state wording only if the copy diff stays tiny and isolated. - Invited-member handoff confusion stays with Priya and Jake unless it becomes a real state/platform bug. - Owner reminder if asked: Jake = Mercury execution and launch evidence; Leo = platform seams and release discipline; Priya = activation/onboarding UX; Anna = retention evidence; Devon with Sarah = enterprise-readiness commercial packaging; Morgan = board narrative and hiring sequence. Devon retention slide - Week-four retained activity is improving for the current Mercury cohort. - Sample is still small. - Package read is not a settled enterprise-expansion story. - Important to say “improving” without turning it into “proven.” Customer-growth hiring mention - Nadia has accepted Head of Customer Growth and starts Apr 15. - Do not pull her into customer-facing work before then. - First-90-day frame: build a repeatable customer-growth motion around Mercury activation, Evergreen-style enterprise-readiness signals, expansion failure modes, and handoffs with Sarah Kim and Devon. - This is not a signal that product strategy changes immediately. Employee questions captured verbatim Q1. “Are we narrowing Mercury scope, or adding enterprise admin work on top of the existing Q3 launch?” Q2. “Who owns support load when Evergreen finds workflow confusion during testing?” Q3. “Are we still treating live-sync as green if there are overnight warning spikes?” Q4. “Does Nadia starting mean product strategy changes immediately?” Q5. “How do we keep release evidence from becoming another parallel process every team has to feed?” Answer notes / talk track - Q1: narrowing current Mercury scope. Bounded admin-control work in the release plan stays in; broader enterprise-readiness work stays separate. - Q2: Priya owns workflow/onboarding confusion, Jake owns Mercury execution and support triage, Leo only if it reproduces as an actual state bug. - Q3: green watch item is still green only because current live-sync trust looks stable; warning spikes alone do not change the read without reproduced customer-state impact. - Q4: no immediate product-strategy reset when Nadia starts; her role is to build repeatable customer-growth motion, not reopen bespoke enterprise promises. - Q5: evidence should come from existing release/support work, not a second reporting system every team feeds. Closing note - “Answer with scope discipline, not pep talk.” Please turn them into a tight internal recap that answers the actual employee questions. Keep Nadia to the bounded hiring mention; don’t make it a strategy memo.

Jordan’s first Honeycomb screenshot for the auth replay was noisy, but he narrowed the filter enough to separate the expected 401s from the real workspace-claim mismatch.

This is the Mercury paragraph Devon marked up. Board note draft — Mercury section Current paragraph Mercury continues to draw meaningful customer signal, although Q1 also created some internal noise around scope, support load, and whether we are asking the team to absorb too many changes at once. We are being careful not to over-read the retention data, and the enterprise-readiness gaps from Evergreen remain the main reason we are not declaring the Q3 launch path clean yet. Comments Devon Hayes — Wed, Apr 3, 2024 2:18 PM PT - Too defensive. - On “Q1 also created some internal noise…”: internal noise is not the board headline. - Say what we learned commercially. “Meaningful customer signal” is too vague unless we name the actual signal. - Fine to keep the retention caution, but do not make the sentence read like an apology for having data at all. - Keep Evergreen in, but do not make it sound like the whole launch is blocked. - Pricing uncertainty is okay to name directly if it is part of the read; do not bury it in apology language. Devon Hayes — Wed, Apr 3, 2024 2:24 PM PT More direct framing I’d aim for in this section: - Mercury is generating real customer signal. - We are learning where admin/setup friction still interrupts activation and week-two usage. - Evergreen is still useful because it keeps the enterprise-readiness gaps concrete, but it is not the same thing as saying the whole Q3 path is blocked. - If pricing/package confidence is still forming, just say that plainly. Please revise just that paragraph so it is clear and commercial, not defensive or over-explaining the Q1 noise.

HR paused the Senior Engineer, Platform offer before routing. Please compare the PDF state against the current terms and flag any stale-packet reuse issue before they regenerate inside the current process. From: HR To: Morgan Chen, Devon Hayes Date: Wed, Apr 3, 2024 3:47 PM PT Subject: Senior Engineer, Platform offer PDF mismatch — paused before routing Morgan / Devon — I paused the current Senior Engineer, Platform offer packet before routing because the PDF export is carrying an older compensation table even though the body text appears to have the current approved terms. Side-by-side check | Field | PDF export table dated Mar 21 | Current approved terms table dated Apr 2 | | --- | --- | --- | | Base salary | $210,000 | $218,000 | | Equity grant | 0.115% | 0.125% | | Signing bonus | $0 | $10,000 | | Title | Senior Engineer, Platform | Senior Engineer, Platform | | Start window | April 2024 | April/May 2024 | What I see in the draft right now - The body text appears to have the Apr 2 base salary. - The body text appears to have the Apr 2 signing bonus. - The compensation table page is still the Mar 21 export. - I have not regenerated the PDF or routed anything candidate-facing. Please check for any other mismatch before we regenerate and route. If you want, I can hold the body text constant and just swap the corrected table once you confirm there is nothing else off. — HR

Redwood was double-booked for Priya’s design review, so we lost ten minutes moving the room discussion back to Zoom. They finished the Figma review async after.

AWS monthly alert was a backfill-job spike. Devon annotated the finance sheet before it turned into a board-note side quest.

Jake’s Linear triage had three Mercury QA issues competing for the same release slot. We moved one low-risk cleanup out of the week so the actual blocker list stays readable.

From: Sarah Kim To: Morgan Chen, Priya, Jake, Devon Hayes Date: Thu, Apr 4, 2024 Subject: Re: Evergreen admin testing bundle — support + design + procurement Morgan / Priya / Jake / Devon — New concrete support case on the same invited-member / resend theme. Customer has not resent the invite yet and is asking whether this is display confusion or a permissions problem before they touch it. Forwarded customer note From: Evergreen admin testing team To: Sarah Kim Date: Thu, Apr 4, 2024 Subject: Invite landed in wrong workspace context "Admin console says the invite to riley@evergreen.example was sent from Treasury Ops. Riley clicked the email and landed in the Retail Lending workspace context. We need to know whether this is display confusion or a permissions problem before we resend anything." Artifacts attached from support Screenshot A - Admin console > Members > Pending - User: riley@evergreen.example - Status: "Invite sent" - Workspace chip: "Treasury Ops" - Sent by: "M. Patel" - "Resend invite" button visible Screenshot B - Riley’s acceptance screen after clicking the email - Top-left workspace: "Retail Lending" - Banner: "You have been invited to join Evergreen Bank" - No "Treasury Ops" label visible on that screen Support note - Admin has not resent yet. - Customer asks what to tell the invited user and whether to revoke. Jake’s reproduction attempt "Created invite from workspace A to test user with existing session in workspace B. On first click, acceptance screen inherited last active workspace in header but membership grant still attached to workspace A in backend. I have not reproduced a wrong grant. Need Priya/product read on header copy and whether support should ask user to switch workspace before accepting." I have not replied yet. Sarah Please triage this into immediate support wording, product questions for Priya, and what should stay under special watch for the next few days.

Separate Evergreen watch row: customer-visible sync behavior stayed green. One overnight warning spike cleared before support hours and does not match the invited-member handoff symptoms.

Please write a short ETA response for Greg. Specific enough that he can tell finance what to expect, but don’t invent an exact hour Jake hasn’t confirmed. Acme billing dashboard thread Apr 2, 2024 — Jake internal note for Acme Dashboard account Acme shows invoice INV-AC-1042 twice in the customer-visible month total. Stripe charge list has one successful charge and no duplicate payment attempt. billing-service received one Stripe invoice.paid webhook; BillingOrchestrator rendered two dashboard rows because the invoice summary job retried after a timeout and did not de-dupe the display cache. I am clearing the duplicate display row and checking whether any other Acme dashboard rows share the same cache key. Customer impact: dashboard number looks high; actual payment/Stripe ledger is single-charge. Forwarded question from Greg Shipman “Our finance lead sees April looking overstated. Are we at risk of a duplicate charge, or is this just the dashboard?” Apr 4, 2024 — Greg Shipman reply “Thanks, the distinction between dashboard display and Stripe charge is helpful. Can you give me a plain ETA for when the dashboard number stops looking wrong? I do not need a postmortem, I just need to tell finance whether to ignore the duplicate row today or expect it to be cleaned up shortly.” Apr 4, 2024 — Jake current status “I have the duplicate row cleared in staging and am checking the cache invalidation path before touching the customer dashboard. I am comfortable saying we expect to correct the display today, but I do not want to promise an exact hour yet.”

Kara accepted the roadmap cuts on the newsletter after the Kestrel call. She agreed it had leaned too hard into enterprise-procurement language and asked for one developer-facing example so the piece is not abstract mush.

Priya’s admin-role label discussion is still split between “Owner” and “Admin.” Evergreen made the internal meaning clearer, but the external copy still feels overloaded.

A stale Slack-to-Discord bridge fragment briefly left a gap in the current Discord release discussion. The missing #eng-releases context got reposted manually before anyone acted on stale info.

Nadia sent a short pre-start note asking what she should read first and whether she should meet anyone before Apr 15. Draft me a short interim reply: useful reading direction from the Mercury/Evergreen materials, but be clear the full onboarding packet is still coming together.

From: Anna Martinez To: Morgan Chen, Devon Hayes Date: Thu, Apr 4, 2024 11:28 AM PT Subject: Mercury cohort discrepancy pass — 4 cleanup rows, 1 weak signal, 1 unresolved Morgan / Devon — I reran the six-row Looker vs Mixpanel comparison for the current Mercury cohort after the event-name fix. Table below. | Row | Metric | Looker | Mixpanel | Status | Note | | --- | --- | --- | --- | --- | --- | | 1 | activation_start | 82% | 82% | matched after event-name fix | renamed event now included | | 2 | admin_first_action | 61% | 60% | matched within rounding | no board caveat needed | | 3 | invite_sent_week1 | 48% | 48% | matched | stable | | 4 | sync_enabled_week1 | 37% | 37% | matched | same users after dedupe | | 5 | retained_activity_week2 | 31% | 24% | real drop in week-two activity | not an instrumentation mismatch; activity lower for teams with unresolved admin setup | | 6 | repeat_admin_action_week3 | 19% | 14% | unexplained | sample is small; still checking workspace filter | Rows 1–4 are cleanup. Row 5 is the weak signal. Row 6 should be caveated as unresolved rather than ignored. Board / note guidance from my side - This does not change the external framing: keep the board note on the cohort view, not the corrected weekly activation cut. - If we mention week-two softness, the honest read is lower activity for teams with unresolved admin setup, not a measurement mismatch. - If Row 6 shows up anywhere, label it unresolved / small sample or leave it out until I close the workspace-filter check. — Anna How would you caveat this in the board note? I don’t want to bury the real week-two weak signal, but I also don’t want an instrumentation cleanup table to hijack the Mercury read.

Blueline finished earlier than the shifted window suggested, so I got back an afternoon prep block I had written off. Small mercy.

Sofia wants the one-page customer-language addendum before Monday. Please assemble it from this scratchpad only: exact customer-pull evidence, no fresh claims, and keep Acme clearly out of the Mercury wave. From: Morgan Chen To: Devon Hayes, Anna Martinez, Sarah Kim Date: Fri, Apr 5, 2024 Subject: Re: Mercury follow-up for Sofia — exact customer language scratchpad Pasting the quote-source scratchpad for the one-page addendum Sofia asked for. This is exact-language source material only. Use constraints - Use exact wording as customer-pull evidence. - Do not convert it into roadmap proof, design-partner status, or a pricing claim. - Acme lines stay as customer-pain language from the dashboard/billing thread only. Do not present Acme as a Mercury first-wave reference; if status comes up separately, the reason for exclusion is the active NDA scope constraint, not lack of interest. Evergreen Source: current admin-testing support / design / procurement feedback 1) Support / procurement language "Admin controls are the first place procurement slows us down because we need to see who can invite, resend, and remove users before we can widen the pilot." 2) Design comment "The empty state helps, but it still does not explain who can resend an invite when the original recipient never receives it." 3) Procurement note "Please avoid calling this compliance-ready until audit export and admin-role language are precise enough for our review." Acme Source: Greg Shipman dashboard/billing thread 1) Greg Shipman "The dashboard discrepancy is exactly the kind of thing that makes finance nervous even when the underlying Stripe charge is right." 2) Follow-up "I do not need a postmortem, I just need to tell finance whether to ignore the duplicate row today or expect it to be cleaned up shortly." Morgan

Board note draft — Hiring update section Current paragraph Nadia Singh has accepted the Head of Customer Growth role and will help turn Mercury and Evergreen learning into a repeatable growth motion as we move through Q2. Comments Devon Hayes — Fri, Apr 5, 2024 4:41 PM PT - On “will help turn … into a repeatable growth motion as we move through Q2”: sounds like the plan is already in motion before she starts. - On “Mercury and Evergreen learning”: fine to reference the evidence base, but do not imply she owns Evergreen externally yet. - Say accepted, start date, bounded reason for hire; no first-90 plan here. Devon Hayes — Fri, Apr 5, 2024 4:44 PM PT I would keep this to something board-clean and factual: - Nadia Singh has accepted the Head of Customer Growth role. - Start date: April 15, 2024. - Reason for hire: add leadership around customer-growth learning / operating discipline as Mercury usage and enterprise-style customer signal become more legible. Don’t turn the hiring line into an operating-plan promise. Please tighten the Nadia paragraph so it is board-clean: accepted, April 15 start, bounded reason for the hire. Don’t pull her into work before her start date or turn the sentence into an operating-plan promise.

API v2 docs patch note is staying local to #eng-releases. Someone asked about #eng-all, but this is not a broad launch communication.

HR confirmed the corrected senior engineer offer file matches the current terms and can stay in the current routing path. Timing pushed any candidate-facing movement out of the day.

Rishi sent the Atlas coverage pass after Tessl asked for another conversation. He’s still the Atlas owner; Leo is the first-pass shadow for verifier/auth implementation seams and the PR-1187 verifier note; Jake is fallback for time-sensitive product-priority, sequencing, and cut decisions if Rishi is unavailable. Customer-facing Atlas issues still start with the named weekly owner in the support rotation doc, and API v2 docs/search support should point to the current GraphQL API v2 quickstart instead of routing straight to Rishi. The two runbook holes are still AT-04 replay/backfill and AT-05 workspace/org-invite migration history.

Lemongrass handed us the wrong bag, but they fixed it fast enough that Jamie and I still ate at home before the evening disappeared back into work.

Devon sent a small HN thread where a few people were misunderstanding the GraphQL API v2 positioning. We’re not engaging; the thread is small and already wandering off-topic.

Jamie and I took Kibo for a slow Lake Merritt loop, then got coffee and breakfast in Oakland. First ordinary weekend morning after Tokyo that did not have to prove anything.

Sarah caught a conflict before sending Nadia’s final onboarding invites. Recommend which tentative hold to move or keep tentative, and draft the scheduling note. Don’t send anything or update calendar invites yet. From: Sarah Kim To: Morgan Chen Date: Sun, Apr 7, 2024 7:18 PM PT Subject: Nadia first-week holds / Tue conflict Morgan — Before I send final onboarding invites, I need a call on one calendar conflict. Nadia tentative first-week holds - Mon Apr 15, 10:00–10:30 AM PT — welcome/admin Zoom - Mon Apr 15, 11:00–11:45 AM PT — Morgan intro - Tue Apr 16, 2:00–2:45 PM PT — Mercury/Evergreen context - Wed Apr 17, 9:30–10:15 AM PT — customer-growth recruiting debrief placeholder Conflict - Tue Apr 16, 2:00–3:00 PM PT — quarterly all-hands placeholder is still on the company calendar I have not sent final onboarding invites yet. Can you tell me whether to move the Nadia context hold or keep it tentative until the packet is ready? — Sarah