Project Context

You are the software engineer leading execution for a Google Meet feature launch: automatic meeting notes generated in Google Docs for Google Workspace customers. The team shipped an internal dogfood version to 8,000 Googlers, but a configuration mistake on your side caused notes to be written to the wrong default Drive folder for 6% of sessions, creating access-control confusion and triggering a temporary pause from Legal and Workspace Security. Leadership still wants an external launch in 6 weeks because the feature is part of a committed Google Workspace Q3 release.

The core team includes 6 engineers, 1 TPM, 1 PM, 1 UX designer, 2 QA engineers, and shared support from Workspace Security and Site Reliability Engineering. The project matters because the feature is expected to improve post-meeting follow-through and is a headline capability for enterprise admins evaluating Gemini-powered Workspace features.

Key Stakeholders

Workspace PM wants to preserve the Q3 launch date and customer commitments. Workspace Security wants stronger permission validation and would accept a delay. Sales is pushing for an early preview for 15 strategic enterprise accounts. SRE wants a gradual rollout with strict rollback thresholds.

Constraints

• Launch deadline: 6 weeks
• Remaining budget for external testing and support: $120,000
• Team capacity: 6 engineers, with 2 engineers also covering 20% on-call duties
• Dependency: updated Drive permission-check API available in 2 weeks
• Launch target: 50,000 Workspace users in wave 1

Complications

1. A staff engineer who knows the Meet-to-Docs integration best is leaving for another team in 10 business days.
2. Legal requires a written remediation plan before external launch approval can resume.
3. Sales has already told 15 enterprise customers to expect access in the current quarter.

Deliverables

1. Build a 6-week recovery and launch plan with milestones, owners, and dependencies.
2. Explain how you would communicate the mistake, remediation, and revised plan to stakeholders.
3. Define the trade-offs between keeping scope, delaying launch, or reducing rollout size.
4. Propose launch gates, rollback criteria, and post-launch monitoring.
5. Identify the top risks and how you would mitigate them.