Skip to main content
BACK TO INDEX
READING_MODE: ACTIVE
2026-06-19 7 MIN

THE 90-MINUTE BLOCK: DEEP WORK SESSION STRUCTURE FOR INTERRUPTED ENVIRONMENTS

You have 5 hours of protected maker time. Now what? The 90-minute block protocol — exactly how to structure each session for maximum output in a role that never stops interrupting.

Written byJosé de Vivar SevillaChief Technology Officer
PART 4 OF 4 IN The Maker-Manager Protocol

The Hybrid Day gives you 5 hours of protected maker time. The async blueprint kills the interruptions that used to destroy it. But neither helps if you sit down with 5 open hours and spend 40 minutes deciding what to work on.

In a role that never stops pulling at your attention, deep work is not a matter of willpower. It's a matter of structure. The 90-minute block is that structure — a repeatable protocol for entering, sustaining, and exiting deep work in an environment designed to prevent it.

I've run this protocol daily for 18 months across four SaaS platforms. It works because it removes every decision except the work itself. You don't decide when to start. You don't decide when to break. You don't decide what to work on. The protocol decides. You execute.

Why 90 minutes

Every deep work framework picks a number. 52 minutes. 120 minutes. The Pomodoro 25. The exact number matters less than the principle: your brain has a finite attention budget per session, and attempting to exceed it yields diminishing returns.

I settled on 90 minutes for a specific reason. It's long enough to enter a genuine flow state — research suggests 10-23 minutes to achieve cognitive immersion after distraction. Below 90, you spend too much of the session getting into state and too little producing.

But it's short enough that the resistance to start is low. A 3-hour block feels like an ordeal. A 90-minute block feels manageable. And two 90-minute blocks with a break produce more than one continuous 3-hour block.

The preparation ritual

Deep work does not start when you open your laptop. It starts the night before.

The night before (5 minutes)

→ Write the single objective for tomorrow's first 90-minute block. One sentence. One outcome. "Ship the WebSocket reconnection handler." Not "work on notifications."

→ Stage the materials. Open the relevant PR. Pull the branch. Open the docs. By morning, you open your laptop and the work is ready for you.

→ Close every browser tab that is not the work. Your brain interprets open tabs as open loops. Close them before sleep so your brain doesn't process them all night.

The morning execution (90 minutes)

5 min: Setup ritual. Close all apps except the work. Phone on airplane mode. Single monitor, one window. Headphones on (no audio). Set a 90-minute timer visible on your desk — not on your phone.

5 min: Context reload. Read the objective you wrote last night. Read the last 20 lines of code you wrote. Read the PR description. Re-enter the problem space.

75 min: Work. Code. Write. Design. The only rule: if you hit a blocker, write it down and keep moving. Do not switch contexts to unblock yourself. Do not open Slack to ask a question. The blocker becomes a note for the transition block.

5 min: Close. Write a 3-sentence note: what you accomplished, what you're carrying forward, what blocked you. Commit or stash your work. Close the IDE. The session is over.

Total: 90 minutes. Net work time: 75 minutes. Blocker management: 15 minutes across the structure.

The 25/5/25/5/25/5 variation

If 90 continuous minutes is too long for your current focus capacity, use the 25/5/25/5/25/5 split — same total time, structured as three sprints with reset breaks:

25 min: Sprint 1. Peak focus. Only the primary objective.

5 min: Reset. Stand up. Walk away from the desk. Do not check email, Slack, or anything work-related. The reset is physical — your brain needs a movement signal to discharge the attention residue from the sprint.

25 min: Sprint 2. Continue the primary objective. If you completed it, start the next atomic task.

5 min: Reset. Same rule. Do not open any async channel during the 5-minute break. The temptation to "just check" is strongest here. Don't.

25 min: Sprint 3. Final push. This sprint should focus on closing — completing the unit of work, committing, and documenting. Do not start something new in sprint 3.

5 min: Close. Same as the 90-minute close ritual above.

The 25/5/25/5/25/5 works well for CTOs recovering from notification addiction. The short sprints feel like less commitment, which reduces the resistance to start. Over 4-6 weeks, graduate to the full 90-minute block.

The two-block morning

A full maker morning runs two 90-minute blocks with a recovery break between.

| Time | Block | Activity | |---|---|---| | 6:00-7:30 | Block 1 | Primary objective — hardest problem, freshest brain | | 7:30-8:30 | Recovery | Walk, breakfast, no screens. This is not optional. | | 8:30-10:00 | Block 2 | Secondary objective — code review, technical design | | 10:00-10:30 | Buffer | Finish last commit, write transition notes |

Block 1 is non-negotiable. Every day, the hardest problem goes here. Block 2 is flexible — if Block 1 extended or an emergency consumed the buffer, Block 2 becomes the recovery.

The recovery hour between blocks is the most important part of the schedule. If you skip it, Block 2 produces half the output of Block 1. Your brain is not a machine that runs indefinitely. It's a muscle that needs recovery between sets.

What to actually work on in each block

The biggest mistake CTOs make with deep work is working on the wrong thing. They protect the time, then spend it answering emails and reviewing PRs. That's not deep work. That's shallow work in a protected environment.

Define a maker block objective by four criteria:

Output-based. "I will have merged this PR" not "I will work on this PR."

Non-delegable. Can someone else do this? If yes, delegate it. Deep work time is for the work only you can do.

Single-threaded. One objective per block. Not three. Not a list. One.

Verifiable. At the end of 90 minutes, you can check yes/no. Did you ship it? Yes or no. No partial credit.

The blocker protocol

You will hit blockers during deep work. The protocol handles them without breaking state.

TRIVIAL (under 2 minutes to resolve): Fix it and continue. Don't switch windows. Don't leave the IDE. Solve it in place.

MODERATE (requires research or context switch): Write it in a blockers file. Describe the blocker and what you need to resolve it. Continue working on what you can do without it. Address blockers during the transition block at 11:00.

CRITICAL (blocked completion entirely): Pause. Assess if this needs an escalation or a different approach. If it needs a conversation, it waits for the transition block — not a Slack message. A 90-second decision to defer is cheaper than a 15-minute context switch to ask someone.

The recovery between blocks

The break between blocks is not "empty time." It's the recovery that makes the next block possible.

→ Physical: Walk outside. 15-20 minutes. No phone. The movement and natural light reset your cognitive chemistry.

→ Mental: Do not think about the work. Let your subconscious process the problem — it often surfaces the solution during the break.

→ Digital: Zero inputs. No phone, no email, no Slack, no social media. The break is a cognitive reset, and any input interrupts the reset.

A 30-minute walk produces more solutions to hard problems than 2 hours of staring at the screen. I've measured this. It's not woo. It's how the brain works.

Metrics that matter for deep work

Track three numbers:

  1. Blocks completed per week. Target: 10 (5 days x 2 blocks). Actual usually settles at 7-8. That's fine. The buffer and recovery are the difference between sustainable and burnout.

  2. Blocker ratio. How many blocks had zero critical blockers? Target: 80%+. If you're below 70%, the async blueprint needs reinforcement.

  3. Output per block. Define output in terms of shipped work, not hours spent. A block that ends with "investigated approach X" is not output. A block that ends with "merged PR #214" is.

Before this protocol, I averaged 1.2 deep work blocks per week that ended with verifiable output. After: 6.4. The difference was not working harder. It was starting with a clear objective, eliminating decisions during the block, and protecting the recovery.

The single rule

Deep work is not about long hours. It's about protected hours with a clear objective and a protocol that keeps you there.

The 90-minute block is the unit of output in the maker-manager system. The Hybrid Day gives you the container. The meeting consolidation gives you the time. The async blueprint gives you the peace. This protocol gives you the structure to fill the container with actual output.

→ One objective. One block. One output.

→ Then recover. Then repeat.

→ Strip the noise. Ship the work.


DID THIS HURT YOUR FEELINGS?

Good. That means it's working. Share it with your team.