Crunch feels like leadership. The deadline's slipping, so you ask the team for a few 60-hour weeks to pull it in. The research says you're probably getting less done, not more. Stanford economist John Pencavel found that output per hour falls sharply past 50 hours a week, and that someone working 70 hours produces about the same as someone working 55. The extra 15 hours are pure loss.
Key Takeaways
- Stanford's Pencavel found productivity per hour drops sharply after ~50 hours a week (Stanford, via CNBC).
- Past ~55 hours the drop is so steep that more hours add almost nothing; 70-hour and 55-hour weeks produce roughly the same output.
- Crunch also raises defects and burnout, so the extra hours can leave you behind.
- Sustainable pace isn't soft; it's the higher-output choice.
The Research
John Pencavel at Stanford analyzed data on working hours and output and found a clear pattern: below about 50 hours a week, output rises roughly in proportion to hours. Past 50, output per hour starts falling, and past 55 it falls so fast that additional hours barely move total output (Stanford, via CNBC). His striking illustration: people working up to 70 hours a week got about the same amount done as those working 55. The extra 15 hours effectively produced nothing.
The dataset Pencavel used is old, munitions-factory records, and he was careful to note the exact threshold varies by the kind of work (the underlying analysis). But the shape of the curve has held up across a century of research: humans have a sustainable output ceiling, and pushing past it trades tomorrow's productivity for the illusion of progress today.
Why It's Worse for Software
Pencavel measured physical output. Software is worse under overtime, not better, because the work is cognitive. A tired engineer doesn't just type slower; they make judgment errors, write subtler bugs, and lose the mental context deep work depends on. Those bugs then cost time to find and fix, often more time than the overtime "saved." So crunch on an engineering team can be net-negative: fewer good decisions and more defects, and the defects surface right when you can least afford them.
| Hours per week | What you actually get |
|---|---|
| Up to ~50 | Output roughly tracks hours |
| 50–55 | Output per hour falling |
| 55–70 | Almost no added output |
| Sustained crunch | Added output offset by bugs + burnout |
A Concrete Version
A team is two weeks behind, so the founder asks for a month of 65-hour weeks. Week one feels productive; adrenaline carries it. By week three, standups are quieter, two people are sick, one is interviewing elsewhere, and a rushed change causes a production incident that eats two days. At the end of the month the feature ships about when it would have anyway, but now the team is fried and the codebase has fresh debt. The crunch didn't buy speed. It borrowed against the next quarter and paid interest in bugs.
The Honest Counterpoint
Short, rare bursts are different from chronic crunch, and pretending no one should ever work a late night is its own kind of dishonest. A genuine one-week push to hit a real launch, followed by real recovery, can work and can even feel good. The problem is sustained overtime as a management strategy: it stops paying off within a couple of weeks and turns negative, because the productivity curve and the burnout curve both bend against you. If you're always in crunch, you don't have a productivity problem you can solve with hours. You have a scoping or staffing problem wearing a crunch costume.
The Staffing Angle
When a team is chronically over 50 hours, the honest fix usually isn't more hours from the same people; it's more people, or less scope. Adding sustainable senior capacity beats grinding your existing team past the point where output flatlines and attrition starts, a pattern we cover in engineering burnout and what the data shows. It's often faster to add a senior engineer for a stretch than to crunch a tired team into diminishing returns and a resignation, which is one practical use of staff augmentation. See available engineers.
Frequently Asked Questions
Does working more hours get more done?
Up to a point. Stanford's Pencavel found output rises with hours until about 50 a week, then output per hour falls sharply, and past 55 additional hours add almost nothing. A 70-hour week produces about what a 55-hour week does.
Why is overtime worse for engineers specifically?
Software is cognitive work. Tired engineers make more judgment errors and write subtler bugs, and those bugs cost time to fix, often more than the overtime saved.
Is crunch ever okay?
A short, rare push toward a real deadline, followed by genuine recovery, can work. Sustained crunch as a strategy turns negative within a couple of weeks and drives burnout and attrition.
What should I do instead of crunching?
Cut scope or add capacity. If a team is chronically over 50 hours, that's a staffing or scoping problem, and adding a senior engineer usually beats grinding a tired team into diminishing returns.
The Bottom Line
Crunch feels like pushing harder; the data says it's mostly pushing water uphill. Output per hour collapses past 50 hours a week, and past 55 the extra time buys almost nothing but bugs and burnout. Treat sustainable pace as the high-output choice it is, and fix chronic overtime with scope or staffing, not with more late nights.
Roberto Espinoza is CEO of Ruzora, which helps US startups hire pre-vetted senior LATAM engineers in 72 hours. See available engineers.
