Designing Your Ideal Post-Burnout Work Week (My Current Schedule)

I used to work seventy-hour weeks and convince myself it was ambition.

It wasn't. It was inertia. The shape of my work had been set decades earlier — long days, constant availability, a vague sense that if I wasn't grinding I was falling behind. That pattern survived multiple jobs, multiple cities, and eventually followed me all the way to a cabin in Alaska where I finally had enough distance to see it clearly.

The thing nobody tells you about burnout recovery is that it's not really about rest. You can take a month off and come back to the exact same patterns that burned you out in the first place. Recovery requires redesigning the structure of how you work — the actual week, the actual hours, the actual rhythms. Not just deciding to "work less" but building a schedule that makes unsustainable work physically impossible.

I've been running my current schedule for about eighteen months now, and it's the first time in thirty years of professional software development that I've felt like the work serves the life instead of the other way around.

---

What Burned Me Out Wasn't the Hours

Let me be specific, because "burnout" has become one of those words that means everything and nothing.

My burnout wasn't dramatic. I didn't have a breakdown. I didn't rage-quit a meeting. What happened was subtler and probably more common: I stopped caring about problems that used to fascinate me. Code reviews felt like obligations. Architecture discussions felt like performances. The creative energy that had driven my career for decades just… evaporated.

The insidious part was that my output stayed roughly the same. I could still ship features, still debug complex systems, still mentor junior engineers. But I was doing all of it on fumes, and the work that used to recharge me — the deep technical problem-solving, the satisfaction of an elegant solution — had become just another task on an infinite list.

When I finally admitted to myself what was happening, I started tracking what was actually draining me versus what was energizing me. The results were uncomfortable.

The draining stuff: context-switching between projects, administrative overhead, meetings that could have been emails, the constant low-grade anxiety of being "available" during business hours, and — this was the big one — working on things I didn't choose to work on.

The energizing stuff: deep technical work on problems I found interesting, writing, building my own products, being outdoors, and conversations with other engineers about ideas rather than deadlines.

The ratio was roughly 80/20 in the wrong direction. Eighty percent of my time was going to things that drained me. Twenty percent was going to things that actually mattered.

---

The Nuclear Option: Redesigning Everything

I moved to Alaska for a lot of reasons, but one of them was forcing a hard reset on the structure of my work. When your nearest neighbor is a quarter mile away and your internet comes from a satellite, certain patterns of work become physically impossible. You can't pop into an office. You can't grab coffee with a colleague. You can't maintain the illusion of constant availability when the satellite loses signal during heavy snowfall.

This forced isolation turned out to be therapeutic. Not because isolation is inherently good, but because it removed the scaffolding that had been propping up unsustainable habits.

Here's what I built in its place.

---

My Actual Weekly Schedule

I'm going to lay this out in detail because the specifics matter more than the philosophy. Every "design your ideal work week" article I've ever read was heavy on principles and light on what the person actually does Monday through Friday. So here's mine.

Monday: Planning and Client Work

Monday morning starts around 7 AM, but the first hour isn't work. It's coffee, a walk if the weather allows it, and reviewing what I want the week to look like. Not a formal planning session — more like a conversation with myself about priorities.

Actual work starts around 8 and runs until noon. This block is reserved for client work — the contracted development that pays the bills. I take on one, sometimes two, active client projects at a time. Never more than that. The constraint is deliberate.

Afternoon is for planning the rest of the week, responding to anything that came in over the weekend, and administrative tasks. Invoicing, email, updating project boards. I try to batch all the administrative stuff into this one afternoon block so it doesn't leak into the rest of the week.

I'm done by 3 PM. Sometimes earlier.

Tuesday and Wednesday: Deep Work

These are the core of the week. Tuesday and Wednesday are for building things — client work in the morning, my own projects in the afternoon.

The mornings follow the same pattern as Monday: focused client work from roughly 8 to noon. No meetings on these days unless something is genuinely urgent.

The afternoons are where Grizzly Peak Software, AutoDetective.ai, and whatever else I'm experimenting with get attention. This is the work that keeps me engaged — the stuff I chose to work on because it's interesting, not because someone is paying me for it.

I protect these afternoon blocks aggressively. They're the difference between a work week that sustains me and one that grinds me down. If a client asks for a Tuesday afternoon meeting, the answer is no. If administrative work tries to creep in, it gets pushed to Monday or Friday.

Thursday: Writing and Content

Thursday is for writing. Articles like this one, documentation for my projects, sometimes outlines for future content.

Writing is the activity I undervalued for the longest time. For decades I thought of it as something I did in addition to "real" work. Turns out it's one of the most valuable things I do — it clarifies my thinking, builds an audience, and creates assets that compound over time.

I usually write from 8 AM to early afternoon, then spend the rest of the day on editing, publishing, or research for upcoming pieces.

Friday: Flex Day

Friday is intentionally unstructured. Sometimes it's a half day. Sometimes I use it for overflow from earlier in the week. Sometimes I spend it on a side project that caught my attention. Sometimes I don't work at all.

The point of Friday is slack in the system. Every schedule that's packed to capacity will eventually fail because life is unpredictable. Having a built-in flex day means that when a client emergency hits on Wednesday or I lose a morning to a plumbing issue, the week doesn't collapse.

Weekends: Off

This sounds obvious. It wasn't, for most of my career.

Weekends are genuinely off. No client work. No email. No "just checking one thing." The laptop stays closed. I go fishing, work on the cabin, read books that have nothing to do with software, or do absolutely nothing.

The hardest part of post-burnout schedule design isn't building the ideal week. It's defending the boundaries you set. Weekends being truly off was the last boundary I established and the hardest one to maintain.

---

The Math That Makes It Work

If you're doing the arithmetic, you've noticed that my work week is roughly 25 to 30 hours. That's not a typo. And here's the thing that took me years to accept: my output at 25 hours is not meaningfully different from my output at 50 hours.

This sounds impossible until you actually measure it. When I was working fifty-plus hour weeks, a huge percentage of that time was low-quality. Context-switching overhead, recovery time after interruptions, the productivity death spiral of afternoons where you're technically working but producing almost nothing.

At 25 focused hours, almost every hour is high-quality. Deep work. No context-switching. No meetings eating the productive parts of the day.

The revenue impact was initially scary. I make less money than I did at peak corporate salary. But I also spend less, need less, and — this is the part that's hard to put a dollar value on — I actually enjoy the work again. The creative energy came back. Problems are interesting again. I write code because I want to, not because I have to.

---

Tools That Enable the Schedule

This schedule wouldn't have been possible five years ago. The reason I can compress meaningful output into fewer hours is largely because of how much leverage modern tools provide.

AI-assisted development is the biggest factor. Using Claude Code for implementation work means I spend more time on architecture and review and less time on the mechanical parts of coding. A task that would have taken me four hours of heads-down implementation now takes an hour of specifying what I want, reviewing the output, and making adjustments.

Automation handles the recurring work. I've built scripts and workflows for most of the administrative tasks that used to eat my time — deployment pipelines, monitoring, content publishing, invoicing reminders.

Asynchronous communication replaces meetings. I don't do regular status meetings with clients. I send detailed async updates. This eliminates the scheduling overhead and the context-switching cost of interrupting deep work for a thirty-minute call.

The combination of these tools doesn't just save time. It changes the nature of the work from execution-heavy to judgment-heavy. And judgment work — the kind where experience matters — is more sustainable because it's more engaging.

---

What I Got Wrong at First

I want to be honest about the failures because the polished version of this story is misleading.

My first attempt at schedule redesign was basically "work the same way but fewer hours." That failed immediately. If you compress the same broken patterns into fewer hours, you just get more stressed because now you're behind.

My second attempt was too rigid. I had every hour blocked out, no flexibility, and the first week something unexpected happened the whole thing shattered. Rigidity is the enemy of sustainability.

My third attempt — roughly what I described above — works because it has structure without rigidity. The blocks are real but not sacred. The flex day absorbs surprises. The boundaries are firm on the things that matter (weekends off, no meetings on deep work days) and flexible on everything else.

I also initially felt guilty about working less. Thirty years of conditioning doesn't disappear because you intellectually understand that overwork is counterproductive. The guilt faded after about three months, when I noticed that my work was better, my clients were happier, and I was sleeping through the night for the first time in years.

---

Advice for Designing Your Own Schedule

If you're coming off burnout — or trying to prevent it — here's what I'd suggest based on my experience.

First, track your energy, not your time. For two weeks, note after each work block whether it left you energized or drained. The pattern will tell you what to protect and what to eliminate.

Second, start with constraints, not goals. Instead of "I want to work on my side project more," try "No meetings before noon" or "Fridays are unscheduled." Constraints are easier to enforce than aspirations.

Third, accept the revenue hit and plan for it. Working less usually means earning less, at least initially. The offset comes from reduced expenses (you'd be surprised how much overwork costs in takeout, convenience purchases, and stress-related spending) and from the long-term value of sustainable output.

Fourth, protect your recovery time like it's a client deliverable. If a client had a hard deadline on Friday, you'd make sure the work got done. Treat your weekends and off-hours with the same seriousness.

Fifth, give it three months. The first month will feel wrong. The second month will feel uncertain. The third month is usually when the new patterns start to feel natural and the benefits become undeniable.

---

The View From Eighteen Months In

I'm writing this on a Thursday, which means it's a writing day. It's mid-morning, the cabin is quiet, and I've got a window looking out at snow-covered spruce trees. Later I'll take the dog for a walk and probably not think about code at all.

This doesn't mean my career is less ambitious than it was. I'm building products, writing regularly, maintaining client relationships, and doing work I'm genuinely proud of. The difference is that the work exists inside a life, instead of the life existing around the margins of work.

If you're an experienced engineer feeling the slow grind of burnout, the answer isn't to push harder. It's to redesign the container. Build a week that's sustainable by default, not one that requires willpower to survive.

The work will get done. It always does. The question is whether you'll still want to do it in five years.

---

Shane is the founder of Grizzly Peak Software, a technical resource hub for software engineers. He builds from a cabin in Alaska.