Energy, attention, the finite week
40 useful hours of attention, not 60. Design the week around it.
The late hours feel like the virtuous ones: after dinner, laptop back open, pushing through because the work is not done. They are the most expensive hours in your week. Your work is infinite and the hours feel elastic, so you stretch them.
They are not elastic, and the first thing that breaks is not the clock but the quality of the work in the back half of the week. Output per hour does not hold steady as the hours climb. It bends down past the first fifty, and in the back half of a long week you produce a fraction of what you did in the front, in tired work that has to be redone. Past your useful forty hours, the extra time is not neutral. For anything that needs real judgment it is negative, because tired decisions generate rework that costs more than the hours that produced it.
So the budget is real: you have forty hours of genuinely useful attention a week. But those forty hours are not interchangeable. An hour at 9am, fresh, is not the same kind of hour as an hour at 4pm after four meetings. Designing the week is not cramming work into every open hour. It is matching the grade of work to the grade of attention you have, and removing everything that does not need you at all.
The idea of finite focus is not new. The writing on deep work already named it: you get a few hours of true concentration a day and everything after that degrades, and switching tasks leaves a residue that drags down whatever comes next. It is right, but almost all of it is written for the solo maker protecting a block of code or prose. Your week is mostly other people. You cannot wall off the calendar and call it a day, and most of the advice stops at "work less" without telling you what to do with the hours past your useful forty.
Grade your hours by energy
The standard advice is time-blocking: put everything on the calendar in its own box. It is a real improvement over a reactive day, but it treats every hour as the same raw material, and they are not. You have a window where your judgment is sharpest. For most people it is the morning. The exact hour matters less than knowing yours.
Spend that window on the work that most needs your best judgment, and protect it from everything else:
- The architecture call where a wrong default costs six months.
- The hard conversation with someone who is struggling.
- The strategy doc that has to be right because forty people will execute against it.
These are the hours where the difference between your peak self and your depleted self is largest, so they are the hours to defend hardest.
You also stop wasting the peak window on work that does not need it. Reviewing a routine change, clearing notifications, a status update: none of these need you at your sharpest. Putting them in the morning is worse than a small loss. It is spending your scarcest resource on something a depleted hour would have handled just as well.
Hold maker and manager in the same week
You still need maker time, and not for nostalgia about writing code. Your judgment about technical work decays if you never do any, and that judgment is most of what you bring to the job. (Why the maker time matters is its own subject.)
But maker time competes directly with the part of managing where people need to reach you. As an IC you could wall off four hours and go dark. You cannot now. If you make yourself unreachable for half the day, you have not protected your focus. You have just moved a pile of small fires into a bigger one waiting at 2pm. So hold both. Protect one real block where you are heads-down on the work, and stay reachable around it, rather than pretending you are an IC who can disappear. Run both in the same week instead of choosing between them.
Make the inbound arrive once
Context switching is the largest silent tax on the week, and the worst version is not the scheduled meeting. It is everything else arriving one piece at a time: the delayed item, the critical bug, the slipping backlog, the release-health flag, each pulling you out of whatever you were in.
The change that bought me the most time was the simplest one. I used to absorb those signals as they came. Something would slip and I would hear about it, drop what I was doing, deal with it, and try to find my way back. The cost was not any single interruption. It was that the whole day stayed open to a kind of signal that did not need to reach me the moment it appeared.
So I built a ritual. I bookmarked the handful of places those signals live: the review queue, backlog health, release health. Every morning, for fifteen minutes, I open them in order, clear what I can, and turn the rest into a short list of actions for the day. That is it. The fifteen minutes is not the win. This entire category of signal now arrives once, at a time I chose, instead of pinging me across eight hours. The day is no longer interrupted by it. Any check you keep doing on the fly deserves the same treatment: collapse it into one scheduled time so it stops breaking up everything else.
Take the work off your plate
Batching reorders work, but the next step removes it. There are two ways to do that.
Delegation gets framed as developing people, which it is, but it is also the most direct way to get time back, and it only works if you treat it that way. Handing something off and then re-absorbing it through worry is not delegation. It is just a delay. A regular check-in makes it real: agree on when you will hear about it and what counts as needing you, and then trust that. That check-in lets you stop carrying the thing in your head between updates, which is where the cost was.
Automation is the blunter version: work that does not need a human at all. Anything repeatable that you do by hand is a standing tax on your week. You are not speeding it up. You are removing it entirely. Getting that work to run without you is the best use of the hours past your useful forty.
Spend the depleted hours on the right grade of work
Past your useful forty, the hours left in the week give you little on their own, and most people respond by either ignoring that and grinding on or treating it as permission to stop at forty. Both miss what those hours are good for. The depleted hours are not worthless. They are just the wrong grade of attention for deep work, and the answer is not to grind harder but to change what those hours are for.
When that focus is gone, the tail of the week is good for exactly the work that does not need your sharpest judgment:
- reading and learning
- the lighter relationship upkeep that keeps you connected without much mental effort
- shallow triage
- setting up the next automation or ritual, the kind of setup that buys you time later
Forcing architecture decisions into a depleted brain produces the rework that made the long hours negative in the first place. Pointing those same hours at the right grade of work makes them genuinely useful again. Do not work less. Match the grade of work to the grade of attention.
Let the calendar show you where the time went
You cannot design what you cannot see. The simplest tool is the calendar, used not as a plan but as a record. Put everything on it: the focus block, the fifteen-minute call, the time to study, the morning ritual. Then at the end of the week, look at where the time went versus where you thought it would. The gap is the lesson. Over a few weeks you start to see the patterns: the recurring meeting that drains your peak window, the category of inbound you never batched, the focus block that keeps getting eaten. Tune from there. (Used as a published, shared artifact the calendar does more. Here it is just your own measurement tool.)
When this is the wrong advice
This design is for a normal week, and not every week is normal. When something is on fire, your sharpest hours go to the fire, and that is right. Being on-call, covering an open role, or a stretch where you are genuinely back to doing IC work will all break the structure for a while. Do not force it through them; that only adds friction. Pick the design back up when the exception passes. Treating every week as the exception is the worse mistake: you never come back to the design, and the sixty-hour week starts to feel unavoidable. It is not. A sixty-hour week is forty useful hours and twenty that produce work you will redo.