For graduate students, postdocs, and early-career mathematicians
It’s 11 PM and you’re staring at a reviewer comment asking about the non-compact case. You know you thought about this six months ago. You remember a conversation with your collaborator, something about a cutoff argument, or maybe it was a different approach entirely, but the notes from that meeting say only “discussed compactness issue.” Three hours later you have reconstructed, more or less, what you figured out before. You submit the revision. Two weeks pass before you realize you resubmitted the same gap.
This is not a story about mathematical ability. It’s a story about infrastructure. And infrastructure, unlike talent, can be deliberately built.
The most productive researchers I know are not simply smarter or more creative than their peers. They have, over time, developed systems: habits and structures that handle the recurring decisions of a career so that cognitive energy is available for the mathematics itself. They triage the literature on a fixed schedule rather than hoping to stay current. They maintain a live list of problems at different stages of ripeness. They have a checklist they run before submitting a paper. None of this is glamorous. All of it compounds.
Mathematical culture rarely discusses this openly. The implicit story is that good work flows from inspiration, and that the surrounding apparatus, the meetings, the papers in queue, the teaching, the grants, is just noise. That story does a disservice to everyone trying to build a career, because it makes the absence of systems feel like a personal failing rather than what it actually is: an infrastructure problem with an infrastructure solution.
What businesses figured out about uncertain work
The objection writes itself: mathematics is not a business. No checklist produces a proof. The creative core is irreducibly uncertain.
True. But consider an industry that makes the same objection and has a sophisticated answer to it: oil and gas exploration. A drilling firm cannot know whether hydrocarbons are present in a given formation, the uncertainty is geological and permanent. And yet these firms do not simply hope. Every prospect gets scored on independent probability estimates. Portfolio decisions ensure that expected value is positive across a program even when individual wells are binary bets. Every dry hole gets a formal post-drill review: which assumption was wrong, and why? The system does not find oil. It ensures that decisions are made consistently, that resources are allocated rationally, and, crucially, that failures become data rather than just money lost.
The principles transfer cleanly. Make uncertainty explicit rather than vague. Separate the decision of whether to pursue something from the execution of pursuing it. Institutionalize the analysis of failure. Maintain a portfolio rather than a single bet. Decide in advance what evidence would cause you to change course. Build adversarial review into the process rather than relying on optimism to catch errors.
The creative work cannot be systematized. But everything around it can be. And systematizing the periphery is what frees up cognitive energy for the center.
What follows is an attempt to make those structures concrete for a mathematical career, across research, teaching, and grants. The specifics differ by career stage, and I’ll note where something matters more at one level than another. But the underlying logic is the same throughout.
Research
Portfolio thinking
Deep focus on a single hard problem is not a mistake. Most genuine breakthroughs require it, and many advisors push for it deliberately, the ability to stay with a difficult problem long enough to understand it fully is a skill that has to be developed. The issue is not focus itself but the structural vulnerability it creates when it’s the only mode you have.
If you are working on one problem at one risk level and that problem stalls, which it will, for weeks or months at a stretch, you are fully blocked. This is the research equivalent of the single-well drilling program: a binary bet with no fallback. The stall doesn’t mean the problem is unsolvable or that you’re not good enough. It means you’ve reached the part where progress requires time, distance, or a new idea you don’t have yet. None of those things arrive faster by staring harder. They arrive while you’re working on something else.
A better structure is a portfolio: one long-horizon, high-difficulty problem that might take years; one medium problem where real progress is being made; and one or two shorter problems that could yield a result within months. When the hard problem stalls, you shift weight to the medium one. You are never fully blocked, and the shorter problems keep the record alive during a hard stretch.
For graduate students, this is constrained by the thesis, but even within a thesis, maintaining two or three related questions at different difficulty levels prevents the paralysis of a single obstruction. For postdocs under publication pressure, portfolio thinking is not optional: it is how you survive a two-year position with something to show for it. For faculty, the failure mode is over-investment in one ambitious project at the expense of the smaller results that sustain a research program between the large ones. The oil and gas analogy is exact: a drilling program with one well is a binary bet. A program with ten wells at varying risk levels has predictable expected value even though each individual well is uncertain.
Information intake
The literature does not stop growing because you are busy. Without a system, staying current degrades into occasional guilty binges followed by long gaps. A fixed weekly triage works better: pick two or three relevant arXiv subject codes, set aside the same block of time each week, and spend a bounded amount, say thirty minutes, scanning titles and abstracts. Papers of interest get filed immediately into a reading inbox, tagged with why you saved them and what they might connect to. The note written at filing time is often more useful six months later than the paper itself.
Talks and seminars deserve the same treatment. A consistent template, main claim, key technique, open questions mentioned, follow-up papers cited, turns a talk into a recoverable artifact rather than a memory that fades during the coffee break after the talk.
Problem management
Maintain a tiered problem list: active problems, simmering problems, and a backlog of ideas not yet ripe. The act of maintaining it prevents tunnel vision and keeps good ideas from disappearing into a busy week. Alongside it, keep a “why I am stuck” log, and most importantly, use it honestly. Being stuck is one of the most disorienting experiences in mathematical research, partly because there is no external signal telling you whether you are two days from a breakthrough or two months from abandoning the approach. The standard advice is to talk to your advisor or a colleague, and that’s good advice. But before you do, writing down the precise obstruction, not something generic like “I’m not making progress” but “the bound breaks at step three because the estimate requires compactness and I don’t have it”. This specificity does two things. It forces a clarity that often dissolves the block on its own. And it means you do not have to reconstruct your position after two weeks away, or explain from scratch in a meeting what you’ve already thought through.
For postdocs managing multiple projects simultaneously while on the job market and writing a first grant, this kind of documentation is not a luxury, it’s the only way to re-enter a problem after a week away without losing a day reconstructing context you already generated.
Equally important is a personal example library: the specific objects that test every new idea in your area. This is your working mental model made explicit and recoverable. Strong researchers almost universally maintain something like this; it is rarely named as a practice.
For approaches that fail, write a brief note on why. What was the obstruction? Which assumption turned out to be false? This takes five minutes and has two benefits: it prevents you from reinventing the same dead end six months later, and it occasionally produces something publishable, a remark, a counterexample, a note on what doesn’t work and why.
The pre-submission checklist
This is perhaps the highest-return intervention in this entire essay. A short formal checklist before submission catches errors that would otherwise waste months of a referee’s time and yours.
- All quantifiers appear in the correct order throughout
- Every hypothesis is stated before it is used
- Every lemma is actually invoked somewhere in the paper
- Special cases checked: empty set, n=0, n=1, degenerate configurations
- Main theorem as stated in the introduction matches its formal statement exactly
- Every “it is easy to see” has actually been verified
- References in the body are consistent with the bibliography
- Paper has been read forward once and backward once
- A colleague has been asked specifically to look for problems, not just to read
Reading backward, checking that each step genuinely uses what precedes it, rather than what you intended to precede it, catches logical gaps that forward reading misses. There is also a real difference between asking a colleague to read your proof and asking them to try to break it.
The meeting log and the capture problem
For ongoing meetings with students and collaborators, a brief log is essential. I keep a daily record of who I met with, what we discussed, where things stood, and what the current obstruction was. The bottleneck in this system is not the logging itself, it is getting enough into the note that it is useful when you return to it a week later.
The fix is structural rather than motivational. Record meetings, or speak a ninety-second voice memo immediately afterward while recall is still fresh. Use a minimal four-field template, main topic, current status, key obstruction, next concrete action, so the decision of what to write is already made. Or close the meeting by asking your student to summarize where things stand; writing their summary takes ten seconds and also reveals whether they understood the conversation the same way you did.
A note that says “obstruction: bound fails in the non-compact case; trying a cutoff argument” took fifteen seconds to write and will still be useful in three weeks. The standard for a useful note is considerably lower than the standard for a complete one. Consistency at low resolution outperforms intermittent high-fidelity entries.
Submission pipeline tracking
Maintain a simple record of every paper: title, target journal, submission date, current status, response date, and resubmission deadline. This takes five minutes to set up and prevents papers from sitting forgotten in a submitted state for months past when you should have followed up. For postdocs under publication pressure, this is not optional.
Teaching systems
Teaching has a structural advantage over research when it comes to systems: it repeats. You will teach calculus again. You will hold office hours again. You will grade the same type of exam question again. Every repeated activity is an opportunity for a system to compound in value across iterations, in a way that is more predictable than in research precisely because the cycle is fixed.
The course build vs. course run distinction
The first time you teach a course, you are designing it. That design effort should not be fully repeated. A master folder structure identical across all your courses means you never spend time looking for things. A course retrospective document, written in the final week of each semester and read before next year’s version begins, captures what worked, what flopped, which examples landed, and which assessment questions were ambiguous.
The failure mode is familiar: the retrospective does not get written because the end of semester is exhausting. The fix is to lower the bar. Four bullet points written on the last day of finals are worth more than a thorough reflection that never happens.
Before the lecture
Before building slides or writing notes, answer four questions:
- What is the one thing students should leave knowing?
- What is the example that makes it concrete and memorable?
- Where is the likely confusion point, and how will I address it?
- How does this connect to what came before?
Five minutes spent here prevents the failure mode of a technically correct but narratively incoherent lecture, the kind where students leave having followed each step but having understood nothing.
Assessment systems
Maintain a question bank with each problem tagged by topic, difficulty, and what misconception it is designed to test. Over a career this becomes a substantial asset. Write grading rubrics before grading begins, deciding in advance what a correct solution looks like reduces mid-grading revisions that create inconsistency across a stack of scripts. Read a sample of ten submissions before committing to the rubric, to surface answer patterns you did not anticipate.
The mid-semester pulse check
End-of-semester evaluations arrive too late to act on. A three-question anonymous form around week six or seven, what is helping your learning, what is getting in the way, what would you change, is a structured early-warning system. It catches problems while there is still time to respond. This is the teaching equivalent of the pharmaceutical firm’s predefined stopping rules: a formal checkpoint where you look at evidence before the outcome is determined.
The advising log
Brief notes after substantive student interactions close the loop when a student returns two weeks later and you cannot remember where they stood. The same minimum viable template applies as for research meetings. This matters most for faculty who are running several student projects simultaneously and cannot hold all of it in working memory.
Grants
Grant writing is where the absence of systems is most visibly costly, and where the business analogy maps most cleanly. A grant is a high-stakes, deadline-driven output that recurs throughout a faculty career. It deserves, and rarely gets, the same systematic treatment as a paper submission.
For graduate students, the grants section matters less immediately, but understanding how grants work before you write one is a genuine advantage. For postdocs beginning to write fellowship applications or small grants, the boilerplate management and post-rejection review advice applies directly. For early career faculty, this section is urgent.
Portfolio thinking for grants
Just as a research problem portfolio reduces the risk of being fully blocked, a grant portfolio reduces the risk of funding gaps. This means maintaining grants at different scales and stages simultaneously: a smaller internal or seed grant, an NSF standard grant, and perhaps a larger collaborative grant further out on the horizon. The portfolio logic is the same as for problems, diversify across time horizons and risk levels so that a single rejection does not create a crisis.
The submission pipeline
Maintain a grant pipeline document analogous to the paper submission tracker: agency, program, deadline, submission date, current status, and review cycle. This prevents the common failure mode of missing a resubmission window because the original rejection got buried in email. It also makes visible whether your grant portfolio has dangerous gaps, long stretches with no active submissions, or over-concentration in a single agency.
Post-rejection review
NSF and NIH panels return written reviews. Treating these as data, which concerns were raised, which assumptions the panel rejected, what the perceived weakness was, and responding to them systematically in a resubmission is directly analogous to the post-drill review in oil exploration. The failure was expensive; extract the information from it. A resubmission that does not explicitly address the panel’s concerns is a common and avoidable mistake. A caveat on this advice, sometimes the comments from the panel and reviews are contradictory, or unclear. Discussion with the Program Officer can provide additional useful information.
Boilerplate management
Maintain a living document containing your current biographical sketch, prior support section, facilities and resources statement, and a set of key references you cite regularly. Update this document when circumstances change, not when a deadline arrives. The cognitive work on any given submission then goes into the science, the specific aims, the research plan, the broader impact, rather than into reconstructing standard material from scratch under time pressure.
The pre-submission checklist for grants
- Specific aims page communicates the problem clearly to a non-specialist reviewer
- Each aim is independently viable if another fails
- Broader impact section is genuinely compelling, not perfunctory
- Budget and budget justification are consistent with each other
- All required sections present and within page limits
- Biosketches current and within format requirements
- A colleague outside your area has read the specific aims
- Prior support section accurately describes outcomes of previous funding
The last item, having a colleague outside your immediate area read the specific aims, is the grant equivalent of asking someone to try to break your proof. A reviewer who does not already understand your problem cannot grant you the benefit of the doubt. If your aims page requires prior knowledge to be compelling, it will not be compelling to a mixed panel.
Tools and logistics
Systems require infrastructure. A few tools are worth naming explicitly because they reduce capture friction, the bottleneck that undermines otherwise good systems.
Reference manager. Zotero or similar. Capture papers at the point of discovery with a one-click browser extension. Do not rely on remembering to add them later.
Version control. Git, or at minimum dated folder snapshots. The ability to recover a proof you deleted three weeks ago is more valuable than it sounds.
Voice memos. For post-meeting and post-lecture capture while recall is still fresh. Transcribe later; the act of speaking is faster than typing under time pressure.
Transcription and AI summary. Record meetings, transcribe automatically, prompt for key points and action items. Reduces the capture burden during the meeting itself to nearly zero.
Plain text or markdown notes. For problem logs, meeting notes, and retrospectives. Prefer formats you can search and that will still be readable in twenty years.
A simple spreadsheet. For paper and grant pipeline tracking. Not a sophisticated tool, a table with columns for status, date, and next action is enough.
The guiding principle for tools is the same as for systems generally: the best tool is the one you will actually use. A sophisticated setup that requires maintenance will be abandoned during the first busy week of semester. Favor simplicity and robustness over features.
The thing nobody tells you
None of these systems are complicated. Most of them take less time to implement than the problems they prevent. The reason they are worth discussing explicitly is that mathematical culture rarely does, the implicit model is that good research flows from talent and inspiration, and that the administrative apparatus of a career is just friction to be endured rather than infrastructure to be designed.
That model is, I think, an artifact of survivorship bias. The researchers who appear most productive have usually, underneath the surface, built structures around their work: they triage literature consistently, they maintain live problem lists, they write things down before they forget them, and they treat failures as information rather than as evidence that they should simply try harder with the same approach. Senior researchers often have versions of these systems too, but informal ones, built by accident over decades, invisible even to themselves, and almost impossible to pass on to the students watching them work. What looks like effortless fluency is often accumulated infrastructure that was never consciously designed and therefore never consciously taught.
The creative core of mathematical work cannot be systematized. But everything around it can be. The purpose of that work is not to produce mathematics mechanically. It is to ensure that when the real insight arrives, you are ready for it, and that you have not spent the preceding three months searching for a paper you read once, reconstructing where you left off, discovering a gap at the referee stage that a checklist would have caught in an afternoon, or missing a resubmission deadline because a rejection got buried in email.
Start small. Pick one system from this essay. Run it for a month or a semester. Then add another.