The Flowtime Technique: the timer becomes a record
It is 2:12 and the function finally works. You wrote it in one run, starting at 1:38, without looking up.
You know the time because you wrote 1:38 on a sticky note before you began, which is very nearly the entire technique.
A 25-minute bell would have rung at 2:03. Nine minutes before it worked.
The timer stops being a rule and becomes a record
Pomodoro asks a question in advance: how long will you work? Flowtime asks it afterwards: how long did you work?
That is a smaller change than it sounds and it moves everything. A rule you can break, and breaking it feels like failing at the method. A record cannot be broken — it can only be inaccurate, and the only person it lies to is you.
So the discipline moves from obeying a bell to writing things down. Everything below is about what to write and when to distrust it.
What Flowtime is, exactly
The technique was written up by Zoë Read-Bivens on Medium in the mid-2010s, after she found that a fixed bell kept cutting her off mid-thought. It sometimes appears under the name Flowmodoro.
Five steps, and none of them take longer than the writing.
- Pick one task and write it down. One line, one verb. Same test as anywhere else: if the line needs the word and, it is two tasks.
- Write the time you started. Before anything else. On paper, in a note, wherever you will actually look later.
- Work until you flag. Not until you are bored for a second — until the work itself gets worse. Rereading the same line, writing code you know you will delete, staring.
- Write the time you stopped, and what pulled you out if something did.
- Take a break in proportion to the block.
Read-Bivens gave figures for that last step, and they are the most useful part of the write-up:
| Block length | Break |
|---|---|
| Up to 25 min | 5 min |
| 25–50 min | 8 min |
| 50–90 min | 10 min |
| Over 90 min | 15 min |
Those numbers came from her own practice rather than a study, and she framed them as suggestions. They hold up mainly because they encode something obvious that people ignore anyway: a ninety-minute block costs more than a thirty-minute one, so it is owed more back.
The log is the technique
Without the log this is just working until you get tired, which you were already doing. The log is what turns it into information. One afternoon looks like this:
` Task Start Stop Pulled out by Break Refactor auth 13:38 14:12 — 8 Refactor auth 14:20 14:51 Slack ×1 8 Write PR notes 14:59 15:14 — 5 Refactor auth 15:19 16:35 phone ×2 15 `
Four blocks, 34 / 31 / 15 / 76 minutes. The shape is the point.
The long block came fourth, not first. That pattern shows up in almost everyone’s log once they keep one for two weeks: the first two blocks are the warm-up you have been resenting yourself for, and they are not a failure of will, they are the cost of loading the problem.
Read the log once a week and it starts answering questions you cannot answer from memory. Which task always produces short blocks. Whether “Slack ×1” appears eleven times on Tuesdays. What time of day your seventy-minute blocks happen — because that hour is worth defending, and until it is written down you will guess wrong about it.
Who it suits
Work with a long warm-up. Code, drafting, design, data analysis, translation, anything where the first fifteen minutes go on getting the problem back into your head. If a fixed bell has ever arrived at the moment you became useful, this is the fix for that specific complaint.
It also suits people who resent being told what to do by a piece of software, which is more of us than admit it.
Does it work for studying?
Partly, and the split is clean. It works for essays, problem sets, and anything with a thread you can lose. It works badly for flashcards, vocabulary and revision, where the monotony is the whole texture of the task and your judgment about when you are flagging is unreliable within ten minutes. For that kind of work a bell is doing you a favour, and the fixed interval is the better tool.
Flowtime against Pomodoro
| Pomodoro | Flowtime | |
|---|---|---|
| Session length | Fixed, usually 25 | Whatever it turns out to be |
| What ends it | A bell | You, when the work degrades |
| Break | Fixed 5 min | Proportional: 5 / 8 / 10 / 15 |
| Best at | Getting started | Not being cut off |
| Worst at | Long warm-up work | Getting a reluctant person moving |
| What you have afterwards | A count | A log with times and interruptions |
| The risk | Stopping too early | Not stopping at all |
That last row is the honest one, and it is the rest of this article.
Nobody rings the bell
Flowtime’s whole design asks you to notice when you are flagging. The problem is that noticing fatigue is the thing you get worst at while tired, so the method leans hardest on the faculty it is degrading.
Some people never stop. Here is what that actually looks like, so you can recognise it in your own log rather than in the abstract:
- The last block ran two hours forty, and you kept nothing from the final forty minutes.
- You skipped lunch because it was going well, and the afternoon that followed produced one email.
- Tuesday had three magnificent hours in it and you could not start anything on Wednesday morning.
- Your log has no interruptions in it at all — which almost always means you stopped writing the log, not that nothing interrupted you.
Three ways to catch it, in order of how much they cost.
Set a backstop alarm at ninety minutes. You are allowed to ignore it. But if you ignore it, you write one line on the log saying why. The writing is the tax, and the tax is what makes the decision conscious instead of automatic.
Use the one-line test when the backstop goes. Say out loud, in one line, what the last twenty minutes produced. Not what you were doing — what exists now that did not exist then. If you cannot, that is the signal. It arrives well before tiredness does.
Read the log on Friday. Any block over about a hundred minutes that is followed by a dead hour is a debt, not a win. One of those in a week is a good week that ran long. Two or three, every week, means the technique is running you and you should put a hard ceiling on block length for a fortnight.
The logic underneath all three: your judgment at minute 110 is not trustworthy and your judgment on Friday morning is. Flowtime works when you let the second one govern the first.
When this is the wrong tool
Your problem is starting, not stopping. If the difficulty is opening the document at all, Flowtime removes the one thing that was helping — a promise to stop, which is what makes a dreaded task cheap to begin. Go and fix that first; most of the reasons timers stop working live on the starting side, not the stopping side.
You work somewhere interruptible. In an open office or a shared flat, every block ends at somebody else’s convenience, and the log becomes a record of other people rather than of you. Fix the environment or schedule a protected block instead, since the block is the part you can actually control.
Time slips away from you. If you routinely surface from a task with no idea whether twenty minutes or two hours have passed — common with ADHD, and not only with ADHD — an open-ended clock is a riskier tool than a bell. Keep the backstop alarm and treat it as non-optional rather than advisory.
Fomodo calls this Deep Work: the clock runs, the block is logged with its length, and there is no bell. Which is also the limitation worth stating plainly.
The app will record a 140-minute block exactly as calmly as a 40-minute one. It has no opinion about the difference, no nudge at the two-hour mark, no way of knowing that the last half hour produced nothing. That judgement stays with you and the log.
One thing we did put effort into: if the app is killed mid-block, or the phone restarts, the session is rebuilt from the wall clock when you come back rather than lost. Losing two hours of work to a crashed timer is the exact experience that makes people stop logging anything, ever.
Write down the time you started. Everything else is a habit you can build later.
