Summary

This bottleneck calculator models a research reading pipeline in four stages: find and triage, read, annotate, and synthesize. Enter minutes per paper and weekly hours for each stage, plus how many papers arrive. It converts them into weekly capacities, names the slowest stage, shows how busy the others are and how fast the unread queue grows, then tests a 25, 50 or 100 percent speed-up on that stage. Based on the Theory of Constraints, it runs in your browser and sends nothing.

Find the Stage Where Your Reading Pipeline Actually Stalls

A free bottleneck calculator for researchers: enter your hours and minutes per paper, and see which stage caps your weekly output.

Run the calculator
A tall stack of papers on the left, a single small tray in the middle, and a short pile of highlighted pages on the right

Bottleneck calculator for a reading pipeline

Enter how long each stage takes per paper and how many hours a week you give it. The slowest stage shows up straight away, with a what-if for speeding it up.

Find and triage

Read

Annotate and take notes

Synthesize and write

0papers per week through
n/aslowest stage
0queue growth per week

How it works

Three rules behind the number

Capacity per stage

Each stage gets a weekly capacity: hours available, converted to minutes, divided by minutes per paper. Six hours at 45 minutes a paper is 8 papers a week. A stage with no minutes entered is treated as skipped.

The slowest stage sets the pace

A chain of stages cannot deliver more than its slowest one. Speeding up any other stage only grows the pile waiting in front of it. The calculator flags that stage and shows how busy the rest are, so idle capacity becomes visible.

A what-if on the constraint

Pick a speed-up of 25, 50 or 100 percent for the slowest stage. Throughput rises until the next-slowest stage takes over, then stops. The result tells you where that happens, which is usually more useful than the raw gain.

Where the estimate is too tidy

  1. 1

    Real work loops back

    The model runs in a straight line. In practice you reread after annotating, and write a paragraph before you finish the reading. Those loops cost time the calculator does not see, so treat its answer as a floor on the problem, not a measurement.

  2. 2

    Minutes per paper is an average

    A 40-page policy report and a six-page note do not cost the same. If your pile mixes both, run the calculator twice, once per type, and compare which stage stalls each time.

  3. 3

    Hours belong to one person

    Each stage has its own hours field, but if you do every stage yourself, those hours come out of the same week. Make sure the four numbers add up to time you really have, or the capacity figures will be flattering.

Reading the result

What to do with the slowest stage

Fix the constraint first

Spend your effort on the stage the calculator names. A better note-taking app does nothing for you if synthesis is the limit, and a faster reader does nothing if annotation is.

Cut what arrives

If the queue grows every week, the cheapest move is often upstream: stricter triage, fewer sources, or dropping papers you would never cite. Lower the arrival number and watch the queue growth fall to zero.

Then change the method

Shorten the slow stage itself. For reading, that can mean pulling the key points and citations out of a long document before you commit to a full read. Rerun the numbers afterwards and see where the wall moves.

Common questions

Is this bottleneck calculator free, and does it send my numbers anywhere?
It is free and needs no account. The calculation runs in your browser, and the figures you type are never uploaded. The only thing that leaves the page is an anonymous count that the widget was used.
What counts as a bottleneck in a reading workflow?
The stage with the lowest weekly capacity. If you can triage 40 papers a week but only synthesize 6, the pipeline delivers 6, whatever the other stages manage. The calculator names that stage and shows how busy each of the others is.
How do I measure minutes per paper without guessing?
Time five real papers at each stage with a plain timer, then average them. A typical reading estimate drifts low, because it forgets the second pass. If your papers vary a lot in length, run the calculator once per paper type and compare.
Why did the bottleneck move after I sped up one stage?
Because capacity is a minimum. Once the slowest stage gets faster than the next one, the next one sets the ceiling. That is why the what-if line reports where the gain stops, and which stage takes over.
Is this the same as a CPU and GPU bottleneck calculator for PC builds?
No. Hardware calculators compare a processor and a graphics card for a game. This one models any serial pipeline of stages, and here it is set up for research reading. The logic is the same idea, the slowest part caps the whole, but the inputs are hours and minutes rather than component benchmarks.
Can I use it for something other than reading papers?
Yes. Treat the four stages as any chain: drafting, review, editing and publishing, for example. The labels are reading-themed, but the arithmetic only needs minutes per item and hours per week for each step.
Where does the method come from?
It is the Theory of Constraints, set out by Eliyahu Goldratt in his 1984 novel The Goal: a chain moves at the speed of its slowest link, so effort spent elsewhere does not raise output. The weekly capacity figure is simply hours divided by minutes per item.

Shorten the stage that stalls

Aginsi reads articles, papers and PDFs for you, with key points highlighted and citations kept. Read less, know more.

See what Aginsi does