Scrolls
5 min read
On this page

Sustainable Pace

Crunch does not work. This is not an opinion -- it is one of the most replicated findings in productivity research. After about 50 hours per week, output per hour drops so sharply that total output barely increases. After 55 hours, total output actually decreases because the errors introduced during exhausted hours create rework that consumes more time than the extra hours produced.

The companies and teams that consistently ship the best software over years (not weeks, not one heroic sprint) are the ones that maintain a sustainable pace. They do not sprint to deadlines and collapse afterward. They run at a speed they can maintain indefinitely.

The Research Is Clear

Studies on sustained work hours have been conducted for over a century, starting with industrial workers and continuing through modern knowledge work research.

Key findings:

- After 50 hours/week, productivity per hour drops significantly
  (Pencavel, Stanford, 2014)

- At 55+ hours/week, total weekly output is roughly the same as
  at 50 hours (the extra hours produce almost nothing)

- Chronic 60-hour weeks produce LESS total output than consistent
  40-hour weeks over a 2-month period (Ford Motor Company internal
  studies, 1920s, replicated many times)

- After 4 consecutive weeks of 60-hour work, developers produce
  the same output as they would working 40-hour weeks
  (Robinson, "Why Crunch Mode Doesn't Work," IGDA)

- Sleep deprivation (common during crunch) impairs cognitive
  function equivalent to legal intoxication at 17-19 hours awake
  (Williamson & Feyer, 2000)

The Ford Motor Company discovered in the 1920s that moving from 48-hour to 40-hour weeks increased total output. This was for factory work. For knowledge work, where quality matters more than quantity, the case is even stronger. A bug introduced at hour 50 can take 10 hours to fix next week.

Why Teams Crunch Anyway

If the evidence is so clear, why does crunch persist? Because it feels productive. Working late feels like commitment. Seeing the team in the office at midnight feels like urgency. And in the very short term (1-2 weeks), you do get more output from extra hours.

The crunch illusion:

Week 1 of crunch:   60 hours, ~55 hours of productive output
                     (Extra 15 hours, 5 hours lost to fatigue)

Week 2 of crunch:   60 hours, ~45 hours of productive output
                     (Fatigue accumulates, error rate increases)

Week 3 of crunch:   60 hours, ~38 hours of productive output
                     (Significant rework from earlier mistakes)

Week 4 of crunch:   60 hours, ~35 hours of productive output
                     (Burnout symptoms, people calling in sick)

Total over 4 weeks: 240 hours invested, ~173 hours of useful output

Compare to sustainable pace:
4 weeks at 40 hours: 160 hours invested, ~155 hours of useful output

Crunch: 50% more hours for 12% more output. And that is before
counting the recovery period.

After a crunch period, teams need 1-2 weeks of reduced output to recover. Factor that in and the "extra" output from crunch often nets to zero or negative.

The Burnout Problem

Crunch is not just inefficient in the short term. It causes burnout, which is catastrophically expensive.

Burnout is not "being tired." It is a clinical condition characterized by emotional exhaustion, depersonalization (cynicism toward your work), and reduced sense of accomplishment. It takes months to recover from, not a long weekend.

Burnout progression:
1. Enthusiasm:       High energy, working extra because you want to
2. Stagnation:       Results plateau, but you keep pushing
3. Frustration:      Work feels pointless, cynicism grows
4. Apathy:           Minimum effort, emotional withdrawal
5. Burnout:          Cannot function, physical symptoms, may need
                     medical intervention

Recovery time at each stage:
Stage 2: A week off
Stage 3: A few weeks of reduced load
Stage 4: 1-2 months
Stage 5: 3-6 months, sometimes requires leaving the job entirely

The cost of losing a developer to burnout -- recruiting, hiring, onboarding their replacement, plus the institutional knowledge lost -- typically exceeds $200k. That is far more expensive than whatever the crunch period was trying to accomplish.

What Sustainable Pace Looks Like

Sustainable pace is not about working exactly 40 hours and stopping. It is about maintaining a rhythm that you can sustain indefinitely without degradation.

Sustainable pace characteristics:
- Consistent hours (roughly 40/week, with occasional variation)
- Regular sleep (7-9 hours per night)
- Weekends are actually off (not "just checking Slack")
- PTO is actually taken (not hoarded and never used)
- After a hard push, there is explicit recovery time
- Energy at the end of Friday is not dramatically different from
  energy at the start of Monday

This does not mean never working more than 40 hours. Occasional spikes are fine -- a production incident, a critical deadline, a conference talk to prepare. The key word is occasional. If "occasional" means every sprint, it is not occasional. It is chronic.

Healthy pattern:
  Week 1: 40 hours
  Week 2: 42 hours (tight deadline)
  Week 3: 38 hours (recovery)
  Week 4: 40 hours
  Average: 40 hours

Unhealthy pattern:
  Week 1: 50 hours (deadline)
  Week 2: 55 hours (deadline slipped)
  Week 3: 60 hours (still pushing)
  Week 4: 45 hours (team exhausted, velocity drops)
  Average: 52.5 hours, declining quality

Setting Boundaries

Sustainable pace requires boundaries, and boundaries require saying no. This is hard for developers who are intrinsically motivated and care about their work.

Boundary examples:

"I can do A or B this sprint, but not both. Which is the priority?"

"I'm not available after 6pm unless there's a production incident."

"I need to take Friday off after this week's on-call rotation."

"This deadline is not achievable without cutting scope or pushing
the date. Here are three options."

"I worked 50 hours last week for the launch. I'm taking Monday
and Tuesday lighter to recover."

The most important boundary is scope. When the deadline is fixed and the team is at capacity, the only variable is scope. Crunch is what happens when teams try to hold all three (deadline, scope, team size) constant. Something has to give, and it should not be the team's health.

The Manager's Role

Sustainable pace is a team norm that managers are responsible for setting and enforcing. Individual developers can set boundaries, but if the manager rewards crunch behavior, the team will crunch.

What managers should do:

- Set realistic deadlines by involving the team in estimation
- Cut scope before asking for extra hours
- Explicitly give permission to work normal hours
- Model the behavior: leave on time, do not send late-night emails
- Celebrate sustainable shipping, not heroic crunches
- Track hours and intervene when someone consistently works 50+
- Plan recovery time after high-intensity periods

What managers should not do:

- "We just need to push through this one sprint" (it is never one sprint)
- Praise the developer who worked the weekend while ignoring the
  one who shipped the same amount in 40 hours
- Schedule deadlines without consulting the team on feasibility
- Send Slack messages at 11pm and expect responses

Recovery & Renewal

Even at a sustainable pace, energy management requires intentional recovery. This is not just weekends and PTO. It is daily and weekly recovery built into the routine.

Daily recovery:
- Actual lunch break (away from the screen)
- Short walks between focus sessions
- Hard stop at end of day (close laptop, not just minimize Slack)
- Evening that does not involve screens or work

Weekly recovery:
- At least one full day with no work-related activity
- Physical activity (exercise is the best recovery tool for cognitive work)
- Social time unrelated to work
- Something creative or engaging that is not programming

Quarterly recovery:
- Actual vacation (not "working from the beach")
- At least 5 consecutive days off (it takes 2-3 days to fully disengage)
- No Slack, no email, no "just checking in"

The 5-consecutive-days rule is important. A single day off does not allow full recovery. It takes 2-3 days to mentally disengage from work, which means a 3-day weekend barely gets you to the starting line of actual rest. A full week off provides 4-5 days of genuine recovery after the disengagement period.

Measuring Sustainable Pace

How do you know if your team is at a sustainable pace? Track leading indicators, not just output.

Metrics that indicate sustainable pace:
- Consistent velocity across sprints (not spiky)
- Low sick day usage
- PTO is being taken (not just accrued)
- Turnover rate below industry average
- Bug introduction rate is stable or declining
- People are learning new things (they have energy to grow)

Warning signs of unsustainable pace:
- Velocity declining over months
- Increasing sick days
- PTO being hoarded ("I can't take time off, we're too busy")
- People leaving (especially your best people)
- Bug rate increasing
- Nobody volunteers for new projects or learning opportunities
- Team morale surveys trending negative

Common Pitfalls

  • "This is just temporary." Every crunch is described as temporary. If you have crunched in 3 of the last 6 months, it is not temporary. It is your culture.
  • Confusing presence with productivity. The developer who is in the office for 10 hours but ships the same amount as the one who works 7 focused hours is not more productive. They are less efficient.
  • Rewarding crunch heroes. If the developer who pulled an all-nighter gets praised in the team meeting while the one who shipped consistently gets ignored, you are incentivizing the wrong behavior.
  • Not adjusting scope. When the deadline is at risk, the answer is almost always "cut scope" not "work more hours." Cutting scope preserves quality and team health.
  • Recovery that is not actually recovery. "I took Friday off but checked Slack all day" is not recovery. Neither is "I was on vacation but answered emails." Real recovery requires full disengagement.
  • Assuming 40 hours means 40 hours of coding. A 40-hour work week includes meetings, email, admin, mentoring, and slack time. If you expect 40 hours of pure coding, you are expecting 55+ hour weeks.

Key Takeaways

  • After 50 hours per week, productivity per hour drops so sharply that total output barely increases. After 55 hours, it often decreases due to error-driven rework.
  • Crunch produces diminishing returns within 2 weeks and negative returns within 4 weeks. The "extra" output is consumed by mistakes and recovery time.
  • Burnout takes months to recover from and typically costs more than $200k when it causes turnover. Prevention is dramatically cheaper than cure.
  • Sustainable pace means consistent 40-hour weeks with occasional spikes followed by explicit recovery. It is not about laziness -- it is about maximizing total output over months and years.
  • When deadlines are at risk, cut scope. Crunch is what happens when teams refuse to adjust scope and instead burn their people.
  • Managers set the pace. Model sustainable hours, celebrate consistent shipping, and intervene when someone is chronically overworking.