Project Background
Anduril's Lattice mission planning workflow is scheduled for a major release in 14 weeks to support a new defense customer field exercise. The team has committed a visible set of operator-facing capabilities: faster route editing, new alerting rules, and improved TAK-compatible export flows. At the same time, the underlying mission graph service has become a delivery bottleneck, causing regressions, slow test cycles, and repeated on-call incidents.
You are the Engineering Manager for a 10-person team responsible for the Lattice mission planning surface and its backend services. Product wants the full feature set in the field exercise because it is tied to a follow-on contract option worth $18M. Engineering believes that without targeted refactoring of the mission graph service, the team risks shipping unstable software and slowing future releases.
Key Stakeholders
Stakeholders include the GM for Lattice, the Product Manager for mission planning, the Staff Engineer who owns the architecture, the Field Operations lead supporting the exercise, and the QA lead responsible for release sign-off. Their priorities conflict: revenue and schedule pressure favor shipping features, while reliability and maintainability favor refactoring.
Constraints
- 14-week deadline with no extension; customer field exercise begins on October 6
- Team: 6 software engineers, 2 QA engineers, 1 designer, 1 TPM; no additional headcount
- Budget: $220K remaining, enough for limited contractor test automation support only
- Current baseline: 11 open Sev-2 defects, deployment rollback rate of 18%, end-to-end test suite takes 3.5 hours
- Staff Engineer is allocated only 40% due to support for a parallel Menace-T integration
Complications
- A recent incident during a demo traced back to legacy mission graph code, increasing executive concern about reliability.
- Field Operations says operators can tolerate one feature slipping, but not instability during the exercise.
- The PM has already previewed all planned features to the customer and is resistant to de-scoping.
Your Task
- Propose how you would decide the split between refactoring and new feature delivery.
- Build a 14-week execution plan, including decision points for de-scoping or phasing work.
- Define what data you would use to justify the trade-off to leadership and the customer-facing team.
- Recommend a launch plan, including quality gates, rollback criteria, and contingency options.
- Identify the top risks if you under-invest or over-invest in refactoring and how you would mitigate them.
