Unit 16 · Phase 1

The First Crisis

When production breaks on a Friday

Friday, 4:47 PM. Pulse Works office. Most of the team is packing up. Ren's phone buzzes — then Hina's laptop pings — then Tetsu's terminal fills with red. The XR demo environment has crashed. The client presentation is Monday morning.

Hina (陽菜) "The staging server is returning 503s across the board. I can't reach the demo at all."

Ren (蓮) "Tetsu, what are we looking at?"

Tetsu (哲) "The rendering service crashed during the catalog sync. It's the module I patched last Tuesday — the one that was in 'Review' for a week."

→ The delayed review from the overloaded Kanban board (Unit 14) has real consequences. When cycle time stretches, rushed patches replace careful reviews — and fragile code ships.

Ren (蓮) "Can anyone else fix it?"

Tetsu (哲) "No."

→ Single point of failure exposed. When one person is on the critical path of every workstream, any disruption — illness, vacation, a Friday crash — becomes a project-level crisis.

Ren (蓮) "Right. Tetsu, you're on the fix. Hina, start documenting everything Tetsu does — if we don't capture this, we'll be here again next month."

→ Ren is applying The Third Way — continuous learning — in real time. Documenting the fix while it happens creates a feedback loop for next time.

Hina (陽菜) "On it. I'll shadow Tetsu and write up every step."

Tetsu (哲) "It's going to be a long night. The patch needs testing, and the catalog data needs to be rebuilt from the last good backup."

Saki (咲希) "I heard from Hina. I'm coming in."

Ren (蓮) "It's Friday night. And you're Company B — this isn't even your problem."

Saki (咲希) "The client presentation is my problem. I'll bring coffee."

She arrived twenty minutes later with four coffees and a printed copy of the demo script. Hers was black. Ren noticed.

Ren (蓮) "Okay. Our WIP limit for tonight is one: fix the demo. Nothing else matters until it's working. Tetsu, tell us what you need."

→ Ren instinctively applies a WIP limit to the crisis itself — a single focus point for the entire team. Under pressure, flow matters more than ever.

Concept Discovery — Crisis as a System Reveal

1 The Bottleneck Under Pressure. When Ren asked "Can anyone else fix it?" and Tetsu said "No," the crisis exposed what the Kanban board hinted at in Unit 14: Tetsu is a single point of failure. The critical path of the entire project runs through one person. This isn't a people problem — it's a system design problem. The Theory of Constraints teaches that every system has a bottleneck; crises simply reveal it faster. Until the team cross-trains or redistributes knowledge, every Friday is a risk.
Tip After a crisis, ask: "What does this failure tell us about the system?" The incident is a symptom. The bottleneck is the cause.

2 The Three Ways in Action. This crisis activated all three principles from The Phoenix Project. Flow: Ren set a WIP limit of one — fix the demo, nothing else — to maximize throughput on the only thing that mattered. Feedback loop: Hina shadowed Tetsu and documented every step, turning the crisis into data the team can learn from. Continuous learning: the documentation means next time, someone other than Tetsu can attempt the fix. The crisis didn't just test the team — it taught them something no planning session could.
Phoenix Project Connection In The Phoenix Project, Brent is the bottleneck everyone depends on. The team only breaks free when they stop routing all critical work through him. Tetsu's Friday night is Ren's wake-up call.

← Stop Starting — Start Finishing After the Storm →