How do I plan my week when a customer emergency or a burning production bug can blow up any day?
The short answer
Build the fire into the plan instead of pretending it will not happen. Commit your calendar to about sixty percent and leave the rest as an unscheduled buffer that absorbs the chaos. When the week is calm you pull forward important-but-not-urgent work into that buffer, when it burns you have room to fight without wrecking your real priorities. A week planned to a hundred percent is a week that fails the first time reality shows up.
Go deeper, your way
3 hand-picked resources, 3 link-checked.
📄 Article
✓ Link checkedFreeIntermediate
Why we picked it
This is the rare piece that gives you the actual number instead of vibes: plan a sprint to about 80% and hold 20% back as an explicit interrupt buffer, because the interrupts are coming whether you budget for them or not. It also solves the part everyone gets wrong, who catches the fire: instead of yanking whoever is nearest off deep work, you rotate one person into an interrupt role for the cycle so the emergency lands on a designated buffer rather than blowing up three people's plans. For a small Indian team where the founder is often the one production issue away from losing a marquee client, that split is the difference between a bad Tuesday and a wrecked week.
Why we picked it
Buffer time only works if the fires eventually get smaller, and this piece is about exactly that: how to stop reactive work from permanently crowding out the important-but-not-urgent work that would prevent the next fire. It uses the iceberg model (events, patterns, structures, mental models) to push you past patching today's crisis toward the leverage points, tiered support, error budgets, incident retros, that quietly reduce how often you burn. It is the counterweight to just leaving slack: the slack absorbs this week's chaos, this frames the quadrant-2 work you pull into that slack on the calm weeks so next month has fewer emergencies.
Why we picked it
Trenchard has watched a lot of founders run their calendars, and his core move is the one that makes buffer-based planning survive contact with reality: block one or two hours against your top three priorities when you are sharpest, then batch the reactive stuff (email, ad-hoc meetings) into defined windows instead of letting it bleed across the day. The practical lever for a founder who cannot escape fires is his insistence on saying no and ending every meeting with a decided outcome, so the reactive load that does hit you is compressed rather than open-ended. Read it as the how of protecting your 60%: guard the priority blocks, fence the firefighting into batches.
