Choose focus length for real client work

The pricing section that ate a whole Tuesday

A few years ago I lost an entire day to one page of a proposal. It was for a small business site rebuild, nothing exotic: a short scope, a timeline, and a pricing section with two options. I sat down at nine with a 25-minute timer running, because that was what I always did, and by five in the afternoon the pricing section still was not finished.

Nothing dramatic went wrong. Each block started with me rereading what I had written in the last one, rechecking the hours I had estimated for the content migration, and reopening the spreadsheet with the numbers. By the time I was actually writing, the timer was two thirds gone. Then it rang, I took my five minutes, glanced at the client channel, answered something small for a different client, and came back to reread everything again. I logged eleven Pomodoros that day. I could have shown you every one of them. What I could not show the client was a pricing section.

The next morning I tried something lazy: three 45-minute blocks, chat closed, one coffee. The section was in the shared doc before lunch. I had not become more disciplined overnight. I had just stopped paying the cost of starting eleven times.

That day is most of what I believe about timed focus for client work. The Pomodoro Technique, which Francesco Cirillo developed in the late 1980s and named after a tomato-shaped kitchen timer, gives you 25 minutes of work, a short break, and a longer break after four rounds. It is a brilliant way to get started on something you are avoiding. It is a teaching default. It was never meant to be the length of every block for every kind of paid work, and treating it that way is how a freelancer ends up with a tidy log and nothing to send.

What follows is how I choose block lengths now, how I keep several clients from shredding them, and how I turn the blocks into dates I can actually promise and invoices I can actually defend.

Name a deliverable the client could open

Before I decide how long a block is, I decide what it is for. A focus block, for client work, is a small timed promise to one named deliverable. The test I use is blunt: when the block ends, will there be something a client could review?

"Draft the pricing section" passes. "Work on the proposal" fails. If I cannot picture the file, the link, or the message that will exist when the timer stops, what I have is a topic, and topics expand until the day is gone. That was the real problem on my lost Tuesday. Every block was labelled "proposal" and none of them had an edge.

Here is the morning I would plan for that same job now. The deliverable is a draft of the pricing section, reviewable by 13:00. I am not designing the whole proposal. I am producing options the client can mark up.

The evidence at 12:25 is a shared-doc link and one clear ask, something like "Which of these fits the budget you mentioned, or should I cut the blog migration from option B?" Three 45-minute blocks are 135 minutes, plus the 25-minute paste, which makes 160 minutes aimed at one section. The morning from 09:00 to 12:25 is 205 minutes of clock time, so about 45 minutes went to the break, the sweep, and the small gaps between blocks. That is not waste. It is what lets the third block be as good as the first.

Two details matter more than they look. The client sweep happens at 10:50, after two drafting blocks, and it has an end time. And the last block is short because pasting and writing a question does not need deep context. Once the stop condition is met, I stop. Extra unpaid polishing on a section the client has not seen yet is scope leak, however virtuous it feels.

If home is the part that breaks the first block (the doorbell, a neighbour drilling, someone who needs a lift at 10:15), the setup for that sits in protect focus when you work from home.

Set block length from what it costs to restart

The single most useful question I have found for choosing a length is this: how long does it take me to get back to where I was? Not how long I can concentrate, not what a productivity app suggests. The restart cost.

Run the numbers once and the case makes itself. Say reopening the file, finding the sentence, and rebuilding the model in your head takes 8 minutes. I timed mine on that proposal afterwards and it was closer to 10, but 8 keeps the arithmetic clean.

A 25-minute block with one setup leaves 17 minutes of real work. That is 17 divided by 25, or 68 percent. Now add one chat ping in the middle that forces a second setup. You have spent 16 minutes on setup and 9 on work, and the ratio falls to 36 percent. You did a Pomodoro. You produced a paragraph.

A 50-minute block with the same single setup leaves 42 minutes of work, which is 84 percent. Same person, same task, same coffee. Different length.

Scale it to an actual job. Say a proposal needs 180 minutes of real writing, not 180 minutes of clock time.

On 25-minute blocks netting 17 minutes each, 180 divided by 17 is about 10.6, so call it 11 blocks. Each cycle is 25 minutes plus a 5-minute break, so 30 minutes. Eleven cycles take 330 minutes, or five and a half hours of clock time, and give you 187 minutes of writing.

On 50-minute blocks netting 42 minutes, 180 divided by 42 is about 4.3, so call it 5 blocks. Each cycle is 50 minutes plus a 10-minute break, so an hour. Five cycles take 5 hours and give you 210 minutes of writing. Less clock time, more drafting.

That is almost exactly my lost Tuesday, minus the bit where I answered other clients in the breaks. The rule I took from it: if setup costs eight minutes or more every time I restart, a 25-minute block is training me to quit during the useful part. I lengthen to 40 or 50, and for genuinely hard debugging I go toward 90. What I do not do is abandon structure and call the rest of the day "flow". Flow with no edge is just a long afternoon. The longer argument, with signs to watch for, is in when a 25-minute Pomodoro is too short.

The break should grow with the block, or the third block of the morning pays for it.

I stand up on every break, and I keep chat closed during it. Checking the client channel is work with its own slot. Calling it a break is how a five-minute pause turns into someone else's priority sitting at the top of your next block.

When I drop the timer altogether

A timer is a boundary. When the work is already bounded by something else, a second clock is noise.

When I skip the clock for exploration, I still write down how it ends. "Stop when three headline options are written" is a stop condition. "Work on the brand until I am tired" is not. Untimed work is fine. An ending that is just exhaustion is not, because exhaustion arrives late and it takes the next morning with it.

The case people forget is the blocked block. Halfway through, it turns out the staging environment is wrong, or I need access the client has not given me, or the answer I need is sitting in someone's inbox. Staring at the remaining minutes will not fix any of that. What I do instead is write one park line with the next action and the blocker, send the question if there is one, and switch to something on my waiting list. I start a fresh named block when the unblock arrives. Spending the rest of the tomato on fake motion is how you end up with a block in the log and nothing behind it.

Before I mark a block complete, I check for one of two things: a reviewable artifact, or a park note. If neither exists, the block was motion, and I log it as that. It is a useful humbling. Over a week it shows exactly which kinds of work I keep starting without a clear edge.

Meeting-heavy days get their own rule. Say there are calls at 09:30, 11:00, and 14:00, and the longest open stretch is 13:00 to 13:40. That 40 minutes gets one named slice of the primary deliverable. Not three small things, one slice. If no gap reaches 25 minutes, I say so in the status note and move the deliverable to a day that can hold it, instead of pretending a run of 15-minute gaps adds up to a block. It does not. Each one starts with setup.

Park one client before you open the next

Several clients multiply the restart cost, and it does not show up as one big loss. It shows up as reopened files, half-written replies, and a faint sense that you were busy all morning. The real cost of context switching goes into the mechanics. For client work my rule is simple: batch one client's deep blocks before I open another client's chat. I do not alternate every 25 minutes because unread badges arranged the day for me.

When I do switch, I park the current block in one line: the next action and the open question. Something like "Proposal: next is to paste option B numbers. Open question is the client's discount cap." That line is enough to restart without rereading the whole morning. I change the task label before I open anything for the next client, and I keep an "up next" list of no more than five items, so the switch has somewhere to go that is not my memory.

Price the switches with your own number. I use 12 minutes for re-entry as a planning figure, but you should replace it with one you time yourself on a normal morning, from "I opened the other project" to "I am editing again". Most people are surprised how long it is.

Four client switches in a morning at 12 minutes each come to 48 minutes. That is nearly two short blocks spent remembering where you were. If you batch client A for two blocks and then move once to client B, you make two switches instead of four and spend 24 minutes. The 24 minutes you bought back is another 25-minute block, or half of a 50-minute drafting block, and you did not have to work any faster to get it.

If the day is mostly switching anyway, I shrink the plan rather than fight it: one primary outcome, one secondary outcome, one communication window. A four-client Tuesday might look like this. Client A gets two morning blocks. Client B gets one after lunch. Client C gets a 15-minute sweep. Client D gets a short status note and a promise of blocks tomorrow. The alternative, replying to everyone all morning and then doing the real work in a heroic evening, is just a day where I never chose a primary. There is more on shaping the whole week around several clients in running a multi-client week without context thrash.

Count blocks before you promise Thursday

The most expensive Pomodoro mistake in freelancing is not a bad block. It is a Friday delivery promised on Monday that quietly needed twelve unnamed hours. I rough-count blocks before I agree to a date now, and it has saved me from more awkward emails than any other habit.

Here is a real-shaped example. A client wants a six-section proposal by Thursday. I estimate 8 blocks of 40 minutes, which is 320 minutes of timed work, or 5 hours and 20 minutes before breaks. My calendar shows 5 free blocks between now and Thursday. Five times 40 is 200 minutes, so I am short 120 minutes, which is three more 40-minute blocks I do not have.

I compare free blocks with the estimate as a ratio. Five divided by eight is 62.5 percent. My personal line is about 70 percent: if the free blocks are under that, I renegotiate the date or the scope before I start, not after. Seventy percent of eight is 5.6, and I have 5, so I am under the line. On Tuesday, not on Thursday night, I either move the delivery to Monday or cut the promise.

Cutting usually reads better to the client than you expect. If one section is one block, five free blocks might cover the outline, three sections, and the paste into the shared doc. So I offer three sections by Thursday and the rest on Monday, and I ask which three matter most. Said on Tuesday, that is a planning conversation. Said on Thursday afternoon, it is an apology.

The blocks need a home in the week, too.

If a client keeps breaking the first blocks with quick calls, I move those calls to a standing afternoon slot and say so in writing, once, politely. Most clients are fine with it. They wanted a reply, not a reply at 09:40 specifically.

A mixed day: fixed fee in the morning, retainer before lunch

Most of my client days are not one deliverable. Here is a full day using the lengths from earlier, mixing a fixed-fee milestone with retainer tickets.

Three 50-minute blocks make 150 minutes. Three 25-minute blocks make 75. Timed work is 225 minutes, or 3 hours and 45 minutes, before lunch and the gaps. That may look small for a "full day". It is roughly what a day with real breaks, a lunch, and a school run in the afternoon actually holds, and quoting from it is honest. Quoting from an imaginary eight hours of uninterrupted blocks is how freelancers end up working evenings to meet dates they set themselves. If that gap between hours worked and hours billed bothers you, it is worth reading why billable hours run lower than working hours.

Five-line block plan template

Client:
Deliverable (reviewable by a link or a file):
Block length and how many:
Stop condition:
Park line if blocked (next action + blocker):

I write this before the first block, usually the evening before. The deliverable line should name a file a stranger could open. The length comes from the restart-cost table. The stop condition is how I end the block when I feel like polishing, which is most of the time. The park line stays blank until I am blocked or switching clients, and then it is the most useful line on the page.

I log the same facts afterwards so an invoice is defensible without a diary of every minute.

Four blocks of 50 minutes are 200 minutes, or 3 hours and 20 minutes. If you bill in quarter hours, that row is 3.25 hours by the usual rounding. Rounding down to 3 hours gives away 20 minutes. Rounding up to 4 bills the client for a lunch you did not work. The log makes the right number obvious and makes the conversation short if a client ever asks.

I also tell new clients one sentence early on: "I keep mornings for delivery and I check messages at 11:00 and 16:00." At the end of each week I look at three things: what shipped, which block lengths matched the work, and which client broke the first block most often. Next week's defaults come from those answers, not from what I hoped would happen.

Retainers leak blocks, fixed fees leak polish

The two common pricing shapes fail in opposite directions, and the blocks make both failures visible.

A retainer tempts always-on chat. The client is paying monthly, so it feels rude to make them wait. What I do instead is write down a block count per week, send a status note on agreed days, and put calls in a standing window. On one maintenance retainer, the agreement was 6 deep blocks a week, and by Wednesday 4 had gone to small ad-hoc questions. That left 2 for the scheduled work. I said so on Wednesday, with the list of questions, and asked which could wait. The client picked two to push to the next week and was slightly relieved to be asked. The alternative was absorbing all six and doing the scheduled work at night, which is exactly the habit retainers are designed to create if you let them. A daily end-of-day status update helps here: the status is the public evidence, and the block count stays in your own log.

A fixed-fee milestone has the opposite leak. Nobody is watching the clock, so the work expands into polish. Here I map blocks to reviewable slices: flow A, flow B, then one revision pass. The timer is optional on fixed fee. The stop condition is not. "Stop when the design link has comments and the checklist is ticked" ends a block. "Make it nicer" never does. The tradeoffs between the two pricing models are in fixed price vs hourly, and when each works.

For a quick reference, this is the picker I actually use on a normal Tuesday, and I keep it for the week unless the work type changes.

If a piece of work needs another stretch, I start a second named block after a real break. Seventy silent minutes is a 50-minute block plus 20 minutes I did not plan and will not remember honestly when I write the invoice.

The thing I would tell my past self, sitting there with eleven Pomodoros and no pricing section, is that the timer was never the unit of client work. The deliverable is. Pick the block length that gets you to a reviewable thing with the fewest restarts, name tomorrow's first client, deliverable, and stop condition before messages get a vote, and let the tomato count fall wherever it falls.