Project Background

At Databricks, your engineering org owns a cross-functional area spanning Databricks Workflows, Unity Catalog integrations, and internal release tooling. Over the last 2 quarters, the team has missed 3 committed milestones, including a Databricks Runtime release dependency that slipped by 2 weeks and a customer-facing launch in the admin console that required a rollback. Retrospectives are happening after each incident and milestone, but they produce long discussion docs and very few durable changes.

You are the Engineering Manager for a 12-person team: 8 engineers, 1 tech lead, 1 product manager, 1 QA lead, and 1 TPM shared across two groups. The VP of Engineering has asked you to redesign the retrospective process before the next quarterly planning cycle, which starts in 6 weeks. The goal is not to improve meeting quality alone, but to make retrospectives reliably change roadmap execution, ownership, and launch readiness.

Key Stakeholders

The VP of Engineering wants fewer repeated execution failures and visible accountability. The Product Manager wants action items that do not consume too much roadmap capacity. The Tech Lead wants deeper root-cause analysis, while the shared TPM wants a lightweight process that can scale across teams. Support and field engineering also care because repeated launch issues increase escalations from strategic customers.

Constraints

• You have 6 weeks before QBR planning
• Only 15% of next quarter's engineering capacity can be allocated to process and reliability improvements
• No new headcount is approved
• The team currently runs 1 retrospective per sprint plus ad hoc retros after incidents
• Two major launch dependencies rely on another Databricks platform team with a history of late handoffs

Complications

1. Engineers are skeptical because the last 3 retrospectives generated 27 action items, but only 6 were completed.
2. One senior PM argues that adding mandatory follow-up work will jeopardize a committed customer launch.
3. A partner team does not attend your retrospectives, even though their delays are repeatedly cited as a root cause.

Your Task

1. Design a retrospective operating model that converts findings into prioritized execution changes.
2. Define how actions will be tracked, staffed, and reviewed in Databricks planning rituals.
3. Propose success criteria for proving the new process is working within 1 quarter.
4. Explain how you would handle stakeholder resistance and cross-team dependencies.
5. Identify the top risks to adoption and how you would mitigate them.