Last quarter had a Tuesday where two clients had a fire at the same time, a Shopify checkout returning 500s and an AWS bill that spiked four times its baseline overnight. I shipped four deploys that day: one to fix the checkout, one to bandage the AWS issue, a third that broke the checkout again, and a fourth that fixed it. By 11:47pm I had one production rollback open and one client awake on the East Coast. The cadence I'd shipped for calm weeks couldn't carry a day like that, and the version I run now grew out of the rewrite that followed. These are the field notes.
Why fractional operator weekly planning has to design for the bad week first
The mistake I made in year one was designing the cadence for the calm weeks. Monday plan day, three build days, Friday ship and retrospect. It worked for about ten weeks out of every quarter. The other two or three weeks, when something actually broke, the cadence snapped: triage ate the plan day along with two build days and the Friday retrospective, and the following week opened on rebuilding the rhythm from scratch.
A bad week, in this practice, is a week with a production rollback, a client crisis that consumes a full day, a sick day, or two of those landing in the same five days. Roughly two weeks per quarter. Not rare enough to design around as the exception. The calm-week version is a calendar. The bad-week version is the architecture.
entry: Tuesday Q1 2026, the four-deploy day
The day I described in the opening was a Tuesday in late January. Shopify 500s at 9:15am. I cancelled a 10am Salesforce review block and deployed the first checkout fix at 10:42am. AWS bill alert at 11:30am. I deployed a bandaid at 1:15pm. By 4pm I had done two more deploys, the second of which broke the first because I had not pulled the latest from the AWS work into the same branch. By 8pm I was firefighting two production environments at once. The lights came back on at 11:47pm. I slept ninety minutes.
The next morning I wrote four rules on an index card. The cadence I run now started there.
What slips first, in order
On Wednesday morning I wrote down what had slipped on Tuesday and in what order. The order has been the same every bad week since.
Writing is the first thing to slip. The article I owed the site, the email to the list, the retrospective note: all of them have no external deadline anyone is waiting on, so they're the cheapest to push. By 11am Tuesday they were already gone from the day.
Planning is next on the chopping block. Wednesday's plan got pushed from Tuesday afternoon to Wednesday morning to Wednesday evening, and the longer planning slips, the more reactive the next day becomes, which is how a bad week extends into a bad three days.
Sleep is the catastrophic one for me. I sleep about three hours a night even on a calm week, and ninety minutes removes most of my decision-making quality for the next forty-eight hours. The decisions I made on Wednesday were measurably worse than the ones I made on Monday, and the ticket history confirms it.
Quality is the last thing to slip and also the irreversible one. The deploy that broke the original checkout fix was a quality slip caused by sleep loss caused by planning slip caused by the writing slip that left me unsure what the day's priorities were. The chain is real, and once you ship a bad change you can only ship a fix on top of it.
Single-context days are the bad-week posture
The calm-week version of my cadence assumes I can run three or four clients in a single day with switches between them. The math works because the context-switching tax across a fractional portfolio is bearable when nothing is on fire. A 15-minute warm-up, a 5-minute wind-down, four blocks. The day costs about an hour of overhead.
That math breaks during a bad week. The switch tax is not linear. Under crisis attention with a sleep deficit, the warm-up doubles or triples. Recovering context for client B when half my brain is still rotating client A's incident is closer to 30 minutes. Stack three of those and the day is gone before lunch.
The bad-week posture is one client per day, maximum. Whichever client is in crisis owns Tuesday. The others get a one-line status note: "I am dark today, will catch up Wednesday morning, here is the trigger that would change that." Then I close their tabs and do not open them. The work that does happen is high quality because it is not interleaved with anything else. The work that does not happen is explicitly chosen and communicated.
The hardest part is closing the other tabs. If something else is also on fire, the one-line status note will surface it within two hours when they reply. I do not need a tab open to find out.
ADHD batching, not time blocking
Time blocking assumes a worker who can switch attention between blocks with low overhead. That worker is not me. I have ADHD and three hours of sleep. Switching from Shopify Liquid to Salesforce Apex to a Python ETL inside the same day is expensive in a way the calendar does not show. By the third switch I am rebuilding mental models faster than I am producing output.
Batching by stack and shape of work is what holds. A Shopify day means everything I touch that day is Shopify-flavored: the cart drawer for client A, the metafield migration for client B, the PDP audit for client C. Three different clients, one stack, one warm-up. Same idea for the shape of the work: writing days hold the week's writing, code days hold the week's code, meetings days hold the week's meetings. ADHD attention recovers from "more of the same" faster than from "different again."
During a bad week the batching becomes more aggressive. The whole day is one client, one stack, one shape. Tuesday becomes "Shopify checkout for client A, all day." Wednesday becomes "AWS triage for client B, all day." Thursday recovers a partial batch on the day's primary client. Friday is the catch-up batch for the writing that slipped earlier in the week.
I run the same template against the Sunday-night decision-support council I keep on hand once a week, which surfaces the bad-week trades before Monday morning rather than during Tuesday triage. Pre-decided trades cost less than during-crisis trades. The architecture is the same one I documented in the agent council case writeup.
One production deploy per day max
This is the rule I wrote on the index card the morning after the four-deploy day. It is the most load-bearing rule in the new cadence.
Production deploy means any change that hits the customer environment. A Shopify theme push, a Salesforce flow update on a production org, an AWS Lambda update, a Vercel deploy to a public domain, a Stripe webhook config change, a schema migration on a customer-facing database. Internal staging deploys do not count. Documentation updates do not count. Local development obviously does not count.
The rule is one of those per day, across all clients combined, not one per client.
Every production deploy carries cognitive load that compounds with the next one if they happen too close together. The first deploy is fine. The second, especially under sleep deficit, is when I start making the kind of mistake that breaks the first. By the third, error rate is high enough that I am almost guaranteed to ship something that needs a hot fix. The cap aligns with how much production change my brain can hold in working memory without cross-contamination.
The honest version of the rule is that the cap is one on a calm day and zero on a bad day. The bad-day cap is more important. If something is on fire, a deploy is allowed only if it is the deploy that puts out the fire. Every other deploy waits until tomorrow.
“The cap aligns with how much production change my brain can hold in working memory without cross-contamination.
”
The exception clause: a deploy is allowed if it is a confirmed rollback of an earlier deploy made the same day. Rollbacks are not "real" deploys; they return the system to a known-good state. I have used this exception three times in eighteen months. Twice it was the right call. Once it was not, and I should have left the bandaid in until the next morning.
What the bad-week schedule actually looks like
The schedule grid in the demo above shows the bad-week version next to the calm-week version. The calm version has four blocks per day, four clients in rotation, plan and ship rituals on Monday and Friday, three build days in the middle. Roughly twenty client touchpoints per week, three or four ships at the end of it.
The bad-week version compresses that. Monday is a single-client day on whichever client has the most active fire. Tuesday and Wednesday are also single-client days, distributed across whoever needs them most. Thursday is a recovery day where I batch the slipped writing, return to the dropped clients with status updates, and reset the mental model. Friday is a partial ship day with whatever survived the week, plus the retrospective.
Total client touchpoints in a bad week: about eight. Less than half the calm-week count. Total ships: usually one, sometimes zero. The output is lower; it is also recoverable, which the four-deploy day's output was not.
The non-negotiables that do not slip even in a bad week are the sleep window (lights out by 1am even if the work is unfinished, because the cost of pushing past 1am is higher than the cost of finishing tomorrow), the deploy cap, and the Thursday status updates to clients I went dark on. Everything else is negotiable. Those three are not.
I document the cadence as part of the practice operating system architecture so it survives me being too tired to remember it. The packaged version of the documents and rituals lives in the Operator's Stack course.
What I would change after two quarters of running this
The plan day still slips and probably should not. The Sunday-night agent council session was supposed to absorb the bad-week trades into the plan, but when Tuesday goes sideways the Sunday plan is also out of date by Wednesday and I rarely sit down to redo it. The fix is probably a 20-minute mid-week replan on Wednesday morning instead of pretending the Sunday version still applies. Not implemented yet.
The sleep window needs a hard floor, not a soft target. The 1am rule held for the first six weeks and started slipping by 30 to 60 minutes during bad weeks. I have not figured out a forcing function that actually keeps it. The honest version is that I have been undisciplined about the floor, not that the floor itself is wrong.
The deploy cap should probably be zero on the worst day, not one. The four-deploy Tuesday started with one deploy that was the "right" deploy, then escalated. If I had held to zero on a confirmed-bad-week day and pushed the first deploy to Wednesday, the cascade would not have happened.
The biggest change is naming bad weeks at the start of them. I have been retroactively recognizing bad weeks on Wednesday or Thursday. The cadence works better if I name a bad week by Monday lunchtime and switch postures immediately. I use a simple flag: three signals out of five and the week is officially a bad-week cadence. The signals are a production rollback open, any sleep night under three hours, any client whose timeline shifted in the last 24 hours, a personal disruption, or a cross-stack switch I cannot batch out of. Two-out-of-five, calm posture. Three-or-more, switch.
Frequently asked questions
Does this work for someone who does not have ADHD?
Probably with smaller adjustments. The slip order generalizes; writing-first, sleep-third, quality-last is what I have observed across solo operators with and without ADHD. The batching aggression is more specific to ADHD; a neurotypical operator may be able to switch within a day at lower cost and could probably run two clients per day on a bad week instead of one. The deploy cap and the single-context-day default are useful for any solo operator under load.
What about clients who insist on multiple deploys per day?
I have not had a fractional client insist on this. What I have had is clients who frame a request as "this needs to ship today" when it actually means "this needs to ship this week." The fix is a one-line response: "I can ship this Wednesday morning and that puts the change in front of users two days earlier than the next calm-cadence window. Acceptable?" Almost always acceptable. The clients who would say no need a full-time hire, not a fractional one. I have written about why fractional is not a cheaper full-time hire.
How do you communicate going dark on three of four clients during a bad week?
A one-line note in each of their channels: "Today is a single-client day on a different account. I will reply tomorrow morning. If something is on fire on your end, reply to this message and I will surface it within two hours." That phrasing has held up across about thirty bad-week communications. Two clients have ever needed me to break the dark posture; in both cases the one-line message itself surfaced what they needed and I handled it in 20 minutes between blocks.
How do you decide which client owns the bad-week single-context day?
Whichever client has the most acute risk, measured in revenue exposure, customer impact, or contractual deadline. Production rollbacks beat feature deadlines. Customer-impacting bugs beat internal stakeholder requests. A regulatory or compliance issue beats almost anything else. If two clients tie, I pick the one whose stack I have been in most recently because the warm-up tax is lower. The decision usually takes 90 seconds, not 30 minutes.
What happens to the writing cadence during a bad week?
It goes to zero on the worst day and recovers on Thursday or the following Monday. The article I would have shipped Tuesday gets pushed to the following week's plan. I do not try to write a shorter version; I have learned that writing produced under bad-week conditions is not worth the time it costs. The output that does ship the next week is sometimes better because the bad week itself often becomes the article, the way this one did.
Is this cadence sustainable for years or just months?
I have run the bad-week version through six quarters. The structure is stable. What has changed is my early-warning recognition, my willingness to declare a bad week earlier, and my discipline on the sleep floor (which is still imperfect). If the practice changes shape, say, dropping from four clients to two, the cadence will need new numbers but the same shape: single-context bad days, deploy cap, slip-order awareness, sleep window non-negotiable.
Sources and specifics
- The four-deploy Tuesday described in the opening occurred in late Q1 2026 across two simultaneous client incidents on different stacks. The deploy count, the rollback, and the 11:47pm finish are accurate to the ticket history.
- The slip order (writing, planning, sleep, quality) has been consistent across six quarters of bad weeks running a four-client fractional practice.
- The "one production deploy per day" cap has held across eighteen months with three documented exception-clause invocations.
- The single-context-day posture comes from observed quadratic switch-tax cost during crisis attention, building on the per-session math in the context-switching cost article.
- The plan day, deploy cap, and sleep window are part of the broader practice operating system documented across the fractional ops cluster, including the four fractional engagement shapes that determine how a week is loaded in the first place.