Edit wiki/math/competition-strategy.md — Work Reflections

---
visibility: public-edit
---

# competition strategy

time management, problem selection, and team dynamics for math modeling competitions. distilled from HiMCM, MCM/ICM (Meritorious, top 10%), M3, MTFC, and USAYPT (2nd nationally).

## the meta-game

modeling competitions aren't just about math. they're about project management under extreme time pressure. MCM/ICM gives you 4 days. HiMCM gives you ~2 weeks but the effective work window is much shorter. the teams that win aren't always the most mathematically sophisticated — they're the ones that manage their time, divide work effectively, and produce a polished paper.

## time allocation

for a 4-day competition like MCM/ICM, my rough allocation:

- **day 1 (first 8-12 hours):** problem selection, research, [[problem-framing]], initial model design. this is the most important day. a bad framing wastes the entire competition.
- **day 2:** core model development. get the math working, get code running, generate initial results.
- **day 3:** refinement, sensitivity analysis, additional models or extensions. start the paper structure.
- **day 4:** paper writing, polishing, proofreading. no new math on this day — if it's not done, it doesn't go in.

the biggest mistake teams make: spending too long on the model and not enough on the paper. judges read the paper, not your code. see [[mathematical-writing]].

## problem selection

when given multiple problems (MCM/ICM offers 6):

- **pick the problem your team can model, not the one that sounds coolest.** FOMO ([[fomo-trap]]) applies here — the "exciting" problem might be outside your team's strengths.
- **prefer problems where you can validate.** if there's real-world data to compare against, your paper is stronger.
- **avoid problems that require domain expertise you don't have** unless you can learn it fast. you can't become a climate scientist in 4 days.
- **read all problems before choosing.** obvious but teams often anchor on the first one that catches their eye ([[information-gathering]]).

## team dynamics

for a 3-person team (standard MCM/ICM):

- **one person owns the paper.** always. writing by committee produces garbage. one person writes, others contribute sections and review.
- **parallelize where possible.** one person on the main model, one on a secondary approach or sensitivity analysis, one on research and paper structure.
- **sync frequently but briefly.** 15-minute check-ins every few hours beat hour-long status meetings.
- **disagree early, commit fast.** the worst outcome is spending day 3 debating something that should have been settled on day 1. see [[reversible-vs-irreversible]] — most modeling choices are type 2.

## the summary page

in MCM/ICM, the summary page is the most important page of the paper. first-round judging often only reads the summary. it needs to:

- state the problem clearly (as you interpreted it)
- describe your approach concisely
- present key results with actual numbers
- highlight what makes your approach novel or strong

don't create suspense. don't narrate your process. state your conclusions upfront. this is not a mystery novel; it's a technical report.

## when things go wrong

they will. models fail, code has bugs, team members disagree. the [[perseverance]] page is relevant here, but so is knowing when to pivot. if your approach isn't working by the end of day 2, pivot. don't spend day 3 trying to save a broken model ([[sunk-cost-and-quitting]]).

the teams that do well aren't the ones that never hit problems — they're the ones that recover fast.