Energy, attention, the finite week

The late hours feel like the virtuous ones: after dinner, laptop back open, pushing through because the work is not done. Your work is infinite and the hours feel elastic, so you stretch them, and they turn out to be the most expensive hours in your week.

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 worse than neutral for anything that needs real judgment, because tired decisions generate rework that costs more than the hours that produced them. Nobody connects the Thursday-night decision to the rework it causes, because the rework arrives days later, filed under ordinary work, so the late hours never get the bill and keep their virtuous reputation.

So the budget is real: you have forty hours of genuinely useful attention a week, and even those forty are not interchangeable, because an hour at 9am, fresh, is a different material from an hour at 4pm after four meetings. Designing the week means 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, everything after them degrades, and switching tasks leaves a residue that drags down whatever comes next. All of that holds, but nearly all of it is written for the solo maker protecting a block of code or prose, and your week is mostly other people. Walling off the calendar is not available to you, 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, though the exact hour matters less than knowing which one is 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 ones to defend hardest.

You also stop spending 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, and putting them in the morning is worse than a small loss, because it spends 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 out of nostalgia for 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. That option went away with the job. Make yourself unreachable for half the day now and you have not protected your focus so much as moved a pile of small fires into one bigger fire waiting for you at 2pm. So hold both in the same week: protect one real block where you are heads-down on the work, and stay reachable around it, instead of pretending to be an IC who can disappear.

Make the inbound arrive once

Context switching is the largest silent tax on the week, and the worst version of it is not the scheduled meeting but everything else arriving one piece at a time: the delayed item, the critical bug, the slipping backlog, the release-health flag, each one 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, 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 but the fact 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, and it is not a sophisticated one. I bookmarked the handful of places those signals live (the review queue, backlog health, release health), and 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. The fifteen minutes themselves matter less than what they changed: this entire category of signal now arrives once, at a time I chose, instead of pinging me across eight hours. Any check you keep doing on the fly deserves the same treatment, collapsed into one scheduled time so it stops breaking up everything else.

Take the work off your plate

Batching reorders the work but does not remove it, and there are two ways to do the removing.

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 but a delay. A regular check-in makes the handoff real: agree on when you will hear about it and what counts as needing you, then trust that. Once the check-in exists you can stop carrying the thing in your head between updates, which is where the cost was all along.

Automation is the blunter version, for work that does not need a human at all. Anything repeatable that you do by hand is a standing tax on your week, and automating it does not speed the task up so much as remove 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 dead at forty. Both miss what those hours are good for. The depleted hours are not worthless, just the wrong grade of attention for deep work, so instead of grinding harder through them, change what those hours are for.

When the real focus is gone, the tail of the week suits 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, and pointing those same hours at the lighter work makes them genuinely useful again.

Let the calendar show you where the time went

You cannot design a week you cannot see, and the simplest instrument is the calendar, used as a record rather than a plan. 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 go, and 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, and forcing the design through those stretches only adds friction, so set it down and pick it back up when the exception passes. Treating every week as the exception is the worse mistake, because then you never come back to the design, and the sixty-hour week starts to feel unavoidable, when it is really forty useful hours plus twenty that produce work you will have to redo.