Time Budgeting Across Parallel Projects

A researcher rarely works on one thing. At any given time there's usually a live signal that needs monitoring, a promising idea half-explored, a data vendor call to follow up on, and a request from a PM that just landed in their inbox. None of these are optional, and there's no formal system most firms hand a researcher for deciding, on a Tuesday morning, which one gets the next two hours.

The idea

The core tension is that maintenance work — checking a live signal's performance, debugging a data feed, responding to a PM's question — is usually urgent but rarely the highest-value use of time, while new research is usually the highest-value use of time but has no deadline forcing it to happen today. Left unmanaged, urgent-but-low-value work reliably crowds out important-but-not-urgent work, because maintenance tasks come with visible consequences for ignoring them (a broken pipeline, an annoyed PM) while research neglect has consequences that are invisible until months later, when a researcher realizes they haven't shipped anything new in a quarter.

Researchers who manage this well tend to use some explicit allocation rule rather than reacting purely to whatever feels most urgent that day — for example, reserving specific blocks of the week for deep research work and treating them as close to non-negotiable as meetings, or capping the fraction of a week spent on maintenance and escalating to a PM or manager when that cap is regularly exceeded, since a persistently high maintenance load is itself a signal that something upstream needs fixing rather than just personal time management. The goal isn't a rigid schedule; it's making the tradeoff visible and deliberate instead of letting the loudest task each day win by default.

A concrete example

A researcher tracks their hours informally for a month and finds that 70% of their time went to responding to ad hoc requests and firefighting a flaky data pipeline, leaving almost nothing for the two new signal ideas they'd been meaning to start. Rather than simply resolving to "work on research more," they make two changes: they block two full mornings a week as protected research time with notifications off, and they raise the recurring data-pipeline issue with the team responsible for it instead of quietly absorbing the maintenance cost themselves every week. Three months later, the same time-tracking exercise shows maintenance down to 30% of their week — not because the underlying requests stopped, but because the researcher stopped treating "urgent" and "important" as the same thing by default.

What this means in practice

A rough allocation across maintenance, new research, and one-off requests, revisited every few weeks, tends to produce far more shipped work over a year than a purely reactive week-to-week approach, even though it can feel less responsive in the short term. It's also a useful diagnostic: if maintenance keeps eating a growing share of a researcher's time despite deliberate protection of research blocks, that's usually a signal about the health of the underlying infrastructure, not a personal productivity problem to push through.