Every plan looks good in the Friday afternoon meeting.
Then Monday happens.
TL;DR: Plans fail because they’re designed for the happy path. Reality isn’t the happy path. The 11pm fix teaches you what the plan missed: edge cases, human factors, and integration points. If you want plans that survive Monday, build them from failures, not from whiteboards.
The Friday Plan
I’ve been in hundreds of planning meetings. The pattern is the same.
Smart people gather around a whiteboard. They draw boxes and arrows. They estimate timelines. They identify dependencies. Everyone nods. The plan makes sense. It’s logical. It’s thorough. It accounts for the major risks.
Then someone schedules a follow-up meeting for implementation.
The energy is good. The confidence is high. The slide deck looks professional.
And none of it matters.
Because on Monday, the plan will collide with reality. And reality wins. Every time.
What Monday Looks Like
Here’s what happens when Friday’s plan meets Monday’s reality:
The edge case nobody considered.
The plan assumed customers submit one order at a time. But your biggest customer submits 500 orders via CSV upload. The system chokes. The queue backs up. Someone gets paged.
The integration that times out.
The API worked in staging. But production has 10x the volume. The timeout settings are wrong. The retry logic is aggressive. Now you’re DDoSing your own system.
The team member who’s on leave.
The plan assumed Jess handles the data migration. Jess is in Fiji for her sister’s wedding. Nobody else knows how the legacy system works.
The workflow nobody documented.
The plan replaces the old order system. But there’s a shadow process in accounting that depends on a specific export format. Nobody mentioned it because nobody knew about it.
The permissions that don’t exist.
The deployment requires production database access. The ops team needs 48 hours to provision credentials. The sprint ends in 24.
These aren’t edge cases. They’re Tuesday.
The 11pm Education
The first time you fix a critical system at 11pm, you’re stressed. The second time, you’re annoyed. By the tenth time, you’re educated.
11pm fixes teach you things whiteboards can’t:
What breaks under load.
Staging is empty. Production is full of real users doing unexpected things. You learn which parts of your system are fragile when they break at the worst possible time.
What depends on what.
The architecture diagram shows clean boxes. Reality shows hidden dependencies. That logging service you didn’t think about? It’s blocking deployments because the queue is full.
How people actually work.
The documented process says users follow steps 1-2-3. The 11pm fix reveals they follow steps 1-3-2-skip-4-repeat-1. The system assumed the happy path. Users don’t take the happy path.
Which workarounds are load-bearing.
Someone built a workaround three years ago. It’s hacky. It’s undocumented. And it’s the only thing preventing a cascade failure. You find this out when you “clean it up.”
This is expensive education. You pay in stress, missed dinners, and career years. But it’s real education. It changes how you plan.
What 11pm Fixes Teach You
After enough late-night firefighting, you start seeing patterns:
| Plans Assume | Reality Shows |
|---|---|
| Users follow the happy path | Users do unexpected things |
| Systems respond instantly | Latency compounds under load |
| Integrations work like docs say | APIs have undocumented quirks |
| Teams have full context | Tribal knowledge walks out the door |
| Timelines are accurate | Dependencies create delays |
| Requirements are complete | Edge cases emerge in production |
The lesson isn’t that planning is useless. The lesson is that planning from a whiteboard produces whiteboard plans. Planning from scars produces plans that work.
Every 11pm fix is a case study in what the plan missed. The question is whether you capture that knowledge or just survive the night and forget.
Building Monday-Proof Plans
I don’t trust plans built by people who’ve never been paged at 2am.
Not because they’re not smart. Because they don’t have the pattern library. They haven’t seen enough failures to anticipate them.
Monday-proof plans are different:
1. They assume failure, not success.
Good plans ask: “What could go wrong?” Great plans ask: “What has gone wrong before?” Every system you’ve seen fail becomes a checkpoint in your planning process.
2. They include the human layer.
Who knows this system? What happens if they’re not available? Where’s the documentation? Who’s on call? Plans that ignore the human layer fail when humans are unavailable.
3. They account for the shadow process.
The documented workflow isn’t the real workflow. The real one has sticky notes, “ask Sarah” steps, and spreadsheets that accounting depends on. Monday-proof plans find these before deployment.
4. They have smaller blast radius.
Don’t migrate the entire system at once. Migrate one piece. Verify. Migrate the next. When something breaks—and something will—the damage is contained.
5. They include rollback.
Every deployment should answer: “If this fails, how do we get back to working?” If the answer is “we can’t,” the plan isn’t ready.
The Gap Between Friday and Monday
The gap between a Friday plan and a working system is enormous.
It’s filled with:
- Edge cases nobody mentioned
- Integrations that behave differently in production
- People who are sick, on vacation, or have quit
- Processes that exist in someone’s head
- Dependencies that don’t show up until go-live
This gap is where projects die. 70% of technology projects fail. Not because the plan was wrong on paper. Because the plan didn’t survive contact with reality.
The consultants who create Friday plans leave before Monday. They never see the failures. They never learn from them. They move to the next engagement with the same blind spots.
Operators stay for Monday. They stay for the 11pm fix. They carry the scars.
That’s the difference.
First Thing Tomorrow
Stop planning from clean assumptions. Start planning from failure experience.
- List your last three fires. Production incidents. Integration failures. Things that broke unexpectedly. What did each one teach you about planning?
- Add “What’s the workaround?” to every plan. Before deployment, identify what people will do if the system fails. That’s your fallback. And if you can’t answer it, you’re not ready.
- Include “Who knows this?” in every section. For each component, name the person who understands it deeply. What happens if they’re unavailable? Document it.
- Run a pre-mortem. Before launch, imagine it failed. What went wrong? Work backwards. Now plan for those failures.
- Make the blast radius smaller. Break the deployment into phases. Each phase should be independently rollback-able. If you can’t roll back, you can’t ship safely.
The goal isn’t to prevent all failures. That’s not possible. The goal is to plan for failures so they’re recoverable.
The Bottom Line
Plans don’t fail because they’re poorly reasoned.
They fail because they’re built for the Friday whiteboard, not the Monday reality.
The 11pm fix is where you learn the difference.
Need plans that survive Monday? I’ve been the one at 11pm. That experience shapes how I plan. Let’s talk.