Eighteen months in, I audited a week I had felt busy for. Roughly six hours had gone into building the product. The rest was support tickets, two calls that could have been emails, an investor update, three hiring conversations, and a long tail of Slack I could not reconstruct at all.
The uncomfortable part was that almost none of it had been wrong to do. That is the actual problem, and it is not about discipline.
Founder work has two true facts that fight each other every day: the job is genuinely reactive, and the work that determines whether the company exists in two years is genuinely non-urgent. Nothing resolves that tension permanently. What works is scheduling rather than a blanket rule: a small protected block that recurs, an escalation path so being unreachable is safe rather than reckless, and acceptance that some weeks you will get none of it.
The standard advice is good advice for the person it was written for. Long uninterrupted blocks, notifications off, ideally a cabin. It assumes your output is a body of work and nobody outside is waiting on your response to proceed.
A founder's job is not shaped like that. If you disappear for four hours, real things stall. A customer who was ready to buy goes cold. A candidate with two offers takes the other one. Your engineer sits blocked on a decision only you can make. These are not imaginary costs invented by an anxious mind, and when advice pretends they do not exist, founders correctly ignore it.
So the honest starting position is: you cannot apply the cabin model, and the answer is not to want it harder.
I want to steelman the other side, because I got this wrong in both directions.
Early on, responsiveness is sometimes worth more than the feature you would have built instead. A customer who emails at 2pm on day three of a trial and gets an answer in ten minutes often becomes a customer. The same person answered at 6pm often does not. When you have forty users, one churning is a meaningful fraction of your company. Speed also buys something you cannot get later: early users tell their friends that the founder answers.
Candidates are similar. Hiring markets move fast, and going quiet for six hours in the wrong week costs you the person.
The mistake I made for six months was treating that as an argument for permanent availability. It is an argument for being fast during defined windows, which is a scheduling question. Nobody actually needs you within ten minutes at 8am on a Wednesday. They need you within a few hours, reliably, and reliability is something you can promise without being always on.
Paul Graham's essay "Maker's Schedule, Manager's Schedule" from 2009 is the clearest description of this I know, and it holds up.
The argument: managers work in one-hour units, so a meeting costs a manager an hour. Makers work in half-day units, so a meeting in the middle of the afternoon destroys the afternoon, splitting it into two pieces too small to build anything in.
The founder problem is that you run both schedules in one head. You are the maker and the manager, so the collision is not between you and someone else, it is internal. You cannot fix it by asking people to respect your calendar, because you are the one who accepted the 2pm.
The practical implication is batching. Meetings go on defined days or defined halves of days, and the remaining half-days stay whole. Two afternoons of back-to-back calls is a better trade than five afternoons with one call each: same meeting hours, completely different amount of building. I do calls on Tuesdays and Thursdays. Tuesday afternoon is grim and I would not go back.
Here is the distinction I wish someone had drawn for me in year one.
Some work compounds: the product itself, architecture decisions, the pricing model, the hiring bar, the documentation that means the next person needs less of your time.
Other work clears. Answering the ticket, sending the update, reviewing the contract, unblocking the engineer. It is necessary and it is genuinely valuable, but it does not accumulate. Tomorrow there is a new pile of the same size.
Both matter. The problem is structural: clearing work has deadlines and people attached, compounding work does not. Nobody messages you asking where the architecture decision is. So on any day you have not deliberately protected it, the compounding work gets dropped, and you can drop it for months with no visible consequence. Then the consequences arrive at once.
The reason to protect a block is not that building is more important than customers. It is that building is the only part of the job with no external force pulling it into existence.
My first attempt was four hours a day, five days a week, no exceptions. It lasted nine days, until a fundraise, a production incident and a resignation landed in the same week and the whole thing collapsed. I did not restart it for two months, because a system you break dramatically is harder to return to than one you never set.
Now I protect ninety minutes, four mornings a week, and treat it as non-negotiable in the way a customer call is non-negotiable.
Ninety minutes sounds unambitious and works for a specific reason: it survives bad weeks. A four hour block gets cancelled the first time something real happens. A ninety minute block usually survives, because almost nothing in a startup genuinely cannot wait ninety minutes. And the gap between ninety protected minutes and zero is the gap between the compounding work existing and not existing.
The other thing that matters: same time every day. Not "when I find a gap," because you will not find one. I run it first thing, before the day has had a chance to make claims on me, and I do not open email before it. Whatever is in the inbox at 8am was in the inbox at 6am and will still be there at 10.
Practically, this is a recurring window in the Deep Focus Weekly Scheduler, which activates the right profile on the days and times I set. The point is not the software. It is that the block exists whether or not I have the judgment to create it that morning, and on mornings when I am tired and behind, I do not have that judgment.
The honest constraint: I cannot be genuinely unreachable. There are things that legitimately cannot wait ninety minutes, though there are far fewer than it feels like at 8:15am.
What I use is a profile that blocks Slack, email and the browser, with two exceptions added as Quick Actions: the tool I am building in, and the one dashboard I sometimes need mid-task. Quick Actions matter more than they sound, because without them I open Slack "just to get the link" and lose the block. I also turn on the system restrictions so quitting the blocker takes deliberate effort rather than a reflex, which matters for the moment twenty minutes in when the work gets hard and my hand moves on its own.
The phone is the harder half. Mine goes face down, out of reach, but not off, because of the escalation path below. That is a deliberate compromise rather than best practice.
This is the piece that made the whole thing work, and it took me too long to build.
You cannot be unreachable. You can be unreachable to everyone except one route.
What surprised me was how little escalation happens. In roughly a year I have been pulled out of a protected block maybe five times, and three of those were right. The fear of being needed is much larger than the frequency of being needed.
Nobody warned me about this part.
Blocking out time to build feels, in the moment, like avoiding the company. Your team is in Slack and you are not. Someone is waiting. There is an unanswered customer email you know the content of. Working while all that sits there produces a low-grade guilt much stronger than the equivalent in a normal job, because in a normal job the consequences are not obviously yours.
Two things help. The first is remembering that the visible work is visible precisely because someone else is waiting on it, and visibility is not the same as importance. The second is having built the escalation path, because then the guilt has an answer: if it were actually urgent, it would have reached me.
I will not pretend the feeling goes away. It just stops being a reason.
I want to be honest that this does not scale cleanly.
At two people, protecting mornings is mostly a matter of deciding to. At fifteen, you are a dependency for far more decisions, and the same ninety minutes creates a queue behind you rather than a delay for you. Founders who make it work at that size are not more disciplined. They have done something structural: pushed decision authority down, hired someone whose job is the reactive surface, or accepted that their impact now runs through other people rather than their own hands.
Some weeks you get nothing. Fundraising weeks, launch weeks, the week someone resigns. Trying to hold the block through those produces a worse outcome than suspending it deliberately and restarting Monday. The failure mode is not missing a week, it is treating a missed week as proof the system does not work.
Ninety minutes to two hours on most days is achievable for most early-stage founders, and more than that is unusual once the company has employees and customers. Consistency matters more than length: four protected ninety-minute blocks a week beats one ambitious four-hour block that gets cancelled.
Yes, with one escalation route left open. Blocking everything makes you genuinely unreachable, which is not responsible at an early stage. Blocking Slack while leaving a single person able to phone you gives you the focus without the risk, and in practice that route is used far less than you expect.
When you have few customers and speed of response converts them, when you are hiring and candidates have competing offers, and during incidents. Early responsiveness is often worth more than the feature you would have built instead. The answer is to schedule those windows rather than being available by default all day.
Give them a promise instead of your presence: a stated window plus a reliable response time. Most of the guilt comes from the team not knowing when you will resurface. Once the rule is explicit and the escalation path exists, the feeling drops sharply.
It gets harder, and eventually it has to change shape. You either push decision-making authority down, hire for the reactive surface, or accept that your building time is largely over. Pretending the same ninety minutes will keep working at forty people is how founders end up as the bottleneck.
I still get the pull most mornings to open Slack first and clear the small things. It never feels like a decision that matters.
The thing I have to keep relearning is that the mornings I gave away never announced themselves. There was no week where I noticed the building time disappearing. There was just an audit, eighteen months in, and six hours where I expected thirty.
Get the latest productivity tips and Deep Focus updates delivered to your inbox
