new file mode 100644
index 0000000..6cdf5cf
@@ -0,0 +1,57 @@
+---
+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.
\ No newline at end of file