The seductive logic and its trap

Instituting a 9-9-6 schedule for a sprint or hotfix can feel pragmatic: customers are waiting, a milestone is slipping, leadership is anxious. But crisis hours are like antibiotics. Used sparingly and for the right diagnosis, they can help. Overused, they breed resistance and leave the team weaker. Once 996 appears even for a justified emergency, the organization learns a shortcut. It becomes the fallback for every hard planning conversation that should have happened earlier.

Emergencies reveal planning gaps; they are not a plan.

Crisis practices ossify into culture

Short-term heroics, repeated, harden into norms:

Be wary of how repetition turns the exceptional into the expected, as new hires model what they observe rather than what is written. Reciprocity pressures also emerge; if one person stays late this week, others feel compelled to do so next week. Soon, planning drift follows, with roadmaps assuming unpaid overtime that masks scope and dependency risk. Ultimately, retention suffers, and the people most able to say no and ship predictably are often the first to leave.

Planning is hard (and that is the job)

Planning is harder than most admit. It means turning uncertainty into staged bets, making tradeoffs visible, and being explicit about risk. It also means saying no. That work often gets skipped because it feels slow or political. The result: emergencies.

Effective planning does a few unglamorous things well:

Effective planning sequences work to reduce dependency risk early, and it sizes scope into thin slices that can ship independently. It relies on historical throughput rather than optimism, and crucially, it reserves time for unknowns and integration, not just feature coding.

Why PMs struggle to estimate

Many project managers are placed without prior shipping experience or apprenticeship. They learn process from training, not from closing real gnarly gaps. Common failure modes:

Limited hands-on shipping reduces intuition for integration and testing time, while little shadowing means the first project is the first time they do the job. Often, weak historical data forces guesswork where optimism fills the void. When incentives reward ambition over delivery, aggressive dates get praise while realistic dates get pushback.

How first-team bias warps future roadmaps

A PM who starts with a rockstar tech lead forms a baseline of delivery that will not generalize. When that lead leaves or the team changes, the mental model stays. Future plans silently assume prior velocity, tool mastery, and system context that no longer exist.

Countermeasure: calibrate to the team you have, not the team you remember. Reset expectations whenever the roster, code surface, or integration points change.

A sustainable alternative to 996

Sustainable pace is a nonfunctional requirement, not a luxury. Treat it the same way you treat security or reliability. The plan should assume normal working hours and still meet its goals. If it cannot, the plan must change, not the hours.

Principles to adopt:

Adopt principles such as making fewer promises with a higher hit rate, and working in smaller batches with more frequent integration. Establish clear definitions of emergency with explicit limits on response, ensuring compensatory rest and follow-through after any truly exceptional push.

Make emergencies rare, not routine

Define what qualifies, in writing. Examples:

True emergencies include production outages with revenue impact, P1 security issues with an exploit in the wild, or regulatory deadlines with legal exposure if missed. Conversely, internal demos, aspirational OKRs, uncontracted sales promises, and scope creep do not qualify.

If you would be embarrassed to explain the emergency to a customer or auditor, it is not one.

Planning mechanics that actually work

Anchor forecasts in data and protect scope first, not hours.

Capacity basics

Use recent throughput, not wishful thinking. Start with a conservative focus factor and adjust with history.

2-week example

focus time is 70% of 8 hours across 5 days

focus_time_per_dev_hours = 5 * 8 * 0.7 team_capacity_hours = devs * focus_time_per_dev_hours * 2 velocity_factor = last_3_sprints_throughput / planned_throughput forecast_capacity = team_capacity_hours * velocity_factor

Scope first, hours last

Commit to outcomes and slices, not to hero hours. When the plan slips, cut scope, stage features, or move the date. Do not pad with overtime.

Buffers and risk

Budget explicit integration time and a risk buffer. Protect it. If you never use it, pull work forward. If you always use it, increase it or reduce scope.

Dependency mapping

List upstream and downstream constraints. Bring owners into planning. Time spent here prevents late surprises.

Thin slices

Prefer feature flags and incremental release. Ship value in steps so feedback comes early and fixes are small.

Definition of done

Done includes tests, monitoring, docs, and runbooks. Work is not done if it cannot be supported calmly.

Role design: experienced dev as PM?

Promoting an experienced developer into a planning role can work well, but it is expensive and fragile if the role collapses into status collection. If you do it, set guardrails:

Ensure the PM leads trade-offs and sequencing rather than just meeting logistics. Assign coordination to a project ops partner so the PM can focus on decisions, and protect focus time to avoid turning the PM into an always-on router. Finally, write a RACI that clarifies who decides what.

Typically, the Tech Lead is Responsible for implementation, while Product/PM is Accountable for scope and priority. QA, Security, and Design are Consulted, with Execs and Sales Informed.

A practical operating model

Weekly cadence

On Mondays, limit WIP and reorder the backlog to reflect real constraints and the newest info. Midweek, conduct a risk review to tackle the scariest dependency or integration first. By Friday, hold a demo and retro, updating forecasts with facts, not feelings.

Quarterly cadence

Set two to four outcome goals, tying each to a measurable customer or reliability metric. Stage large bets into monthly increments with integration points.

Daily discipline

Swarm on blockers and do not start new work while old work is stuck. Keep PRs small, integrate often, and deploy behind flags.

Metrics to guard the culture

Pick a small set and review weekly.

Track plan accuracy by comparing delivered scope to committed scope each month. Monitor the after-hours rate, setting an SLO (e.g., under 5%) for weeks with any after-hours work. Watch emergency frequency per quarter to ensuring the trend declines. Use lead time and throughput to forecast instead of story points alone, and keep aging WIP low by limiting work in progress.

plan_accuracy = delivered_scope / committed_scope after_hours_rate = weeks_with_overtime / total_weeks

Using 996 for crises is a cultural decision disguised as a scheduling tweak. It trades short-term movement for long-term fragility. Treat sustainable pace as a requirement, define emergencies tightly, plan with data, and design roles so experienced leaders make trade-offs rather than take notes. Do that consistently and you will ship more, lose less sleep, and keep your best people longer.

Operationalizing Sustainable Pace

Moving away from a 996 culture requires more than just a policy change; it requires an operational shift. You cannot simply tell people "go home at 5 PM" if the roadmap still assumes they are working until 9 PM. That gap between policy and reality breeds cynicism faster than almost anything else.

The "Red Alert" Protocol

To break the cycle, you need a formal mechanism for declaring an emergency. Create a specific "Red Alert" status that leadership must explicitly trigger. When active, overtime is authorized, food is paid for, and—crucially—compensatory time off is accrued at a premium rate. Having to sign a physical or digital form to trigger this friction makes managers think twice about whether a feature delay is truly a crisis.

Watch the "Quiet Hours"

The most dangerous form of 996 is the one that doesn't look like it. It's the Slack message sent at 8 PM that doesn't demand a reply but implies one. Leaders must model the disconnection. If you work late, schedule your messages to send at 9 AM the next day. If the boss is online, the team feels they must be too.

Signs of Recovery

You see the culture healing when a team member feels safe enough to say, "I can't get that done by Friday unless we cut scope," and the manager replies, "Okay, let's look at the scope." When the answer to a deadline pressure is a conversation about trade-offs rather than a silent commitment to overtime, you have effectively operationalized sustainable pace.