Recover a Launch After Team Strain

Project Context

Google Meet is preparing a 10-week launch of a new AI-generated meeting recap feature for Google Workspace enterprise customers. The work spans 11 people across engineering, product, UX, legal, and GTM, and the feature has executive visibility because Sales has already positioned it to 25 design-partner customers for the next quarterly release.

Two weeks into execution, you notice the tech lead is missing review deadlines, becoming quiet in standups, and privately admits they are overloaded: they are carrying the recap pipeline design, supporting a Sev2 issue in Google Meet recording, and mentoring a new engineer. If this continues, the project is likely to miss integration testing and launch readiness.

Key Stakeholders

The Director of Product wants the feature launched this quarter to support Workspace retention goals. Legal requires review of summary storage and admin controls before any external rollout. Engineering management wants to avoid burnout and protect reliability for the core Google Meet recording stack. Sales wants at least a limited customer launch for committed accounts.

Constraints

• Launch deadline: 10 weeks from today
• Remaining budget: $120,000 for vendor QA and limited contractor support
• Team: 6 engineers, 1 UX designer, 1 PM, 1 TPM, 1 legal partner, 1 GTM lead
• Dependency: Admin controls in Google Admin console must be ready by Week 7
• Reliability requirement: no increase above 0.15% in recording-related error rate during rollout

Complications

1. The struggling tech lead is the only person who fully understands one critical summarization service integration.
2. A VP has asked whether 10 pilot customers can still be included in the quarter, even if the full launch slips.
3. Legal has flagged possible data retention concerns for EMEA customers, which may require scope changes.

Your Task

1. Create a recovery plan for the next 10 weeks that addresses the overloaded team member without derailing launch readiness.
2. Define what work you would de-scope, reassign, or phase to protect the core launch.
3. Propose how you would communicate status and trade-offs to Product, Engineering, Legal, and Sales.
4. Identify the top execution risks and mitigation steps.
5. Define launch success criteria, including pilot vs. full rollout thresholds.