Crunch

Every industry has the situation where a fixed date arrives before the work does. Software hits it especially often because you can't know how long something takes until you're building it. The discovery that a four-week feature is really a six-week feature usually lands in week three.

At that point there are exactly three options: move the date, cut what you agreed to build, or spend more hours. The first two change a promise made outside the team, so somebody has to take responsibility and say it out loud. The third can start inside the team without telling anyone.

That's how the third became the default. A meeting two weeks before a launch typically ends with someone saying the team should just push hard for the next two weeks. Nothing has been cut, the date hasn't changed, and the meeting is over.

Crunch is the name for those two weeks. The word came over from game development, where it described the months before a title shipped, and now it covers any stretch where a software team piles on hours ahead of a release. Naming it is what made it possible to treat the period as something to manage rather than as weather.

What's missing isn't people or skill, it's hours, so the team adds hours per person to cover the difference. Five people moving from 8-hour days to 12-hour days for two weeks produces 1.5 times the time on paper. While that arithmetic holds, crunch genuinely works.

The window where it holds is short. Output rises with hours for roughly the first week or two, and after that three things happen at once.

1. Mistakes multiply. Code written while tired carries more defects than usual, and the time spent finding and fixing them comes straight back out of the hours that were added.
2. Debt piles up. Under time pressure people skip code review and leave temporary shortcuts in place. That deferred cleanup is technical debt, and the two weeks crunch bought get repaid next quarter with interest.
3. Recovery stops working. By around the third week a weekend off no longer restores Monday's concentration. Let that continue and it turns into burnout, and while that person recovers their share lands on everyone else.

So crunch is closer to borrowing time than to creating it. The hours come out of the next cycle. Borrow once and pay it back and it's a usable tool; borrow again before repaying and the balance keeps dropping.

Who decides also changes what the period does to a team. A crunch the team chose, with a scope it agreed to and an end date it named, reads differently from one announced to it. The hours can be identical; what differs is whether people believe the date will actually arrive. Open-ended crunch — where the end keeps moving a week at a time — burns through goodwill faster than a longer stretch with a fixed finish.

Length and frequency are what separate the two cases. Two weeks, once a year, with recovery time attached afterward is something a team absorbs. Every quarter with no recovery is how people end up resigning.

It appears most often when a date is written into a promise made outside the team — an investor presentation, a conference booth, a delivery date in a contract with an enterprise customer. Dates like those didn't come from the team and are treated as immovable, so deadline pressure converts directly into crunch.

Something similar happens right after an outage, though its character is different. Staying up all night while the service is down is closer to firefighting than to crunch. Crunch exists to ship planned work; firefighting exists to undo something that already broke.

The word itself gets used in two kinds of moments. One is the announcement: saying the next two weeks are crunch also means nobody should bring the team anything else in that window. The other is the review afterward. When someone says in a retrospective that the team covered it with crunch again, that's a proposal to go find why the same point keeps slipping.

It's also a question candidates ask in interviews. How often crunch happens tells you more about how a company handles planning than most of what's on the careers page.

"Let's crunch the two weeks up to launch. We take a week off once it ships."

Opening the period explicitly, with the repayment scheduled at the same time.

"This isn't a gap crunch can close. We have to cut scope."

More hours still won't be enough, so reduce what gets built.

"Last quarter was crunch and this one is too. That means the estimates are wrong."

Once is an incident; twice is a planning problem.

Pagedeck signed a large enterprise customer last year and wrote the delivery date for permission management into the contract. Three weeks out it became clear the work was bigger than expected, and Theo and the engineering team spent two weeks staying late to make the date. They made it.

The next two sprints went into cleaning up the shortcuts from those two weeks, and Mia pushed everything she'd planned for those cycles backward. Grace's response was a rule that engineering estimates come in before a date goes into a contract. That doesn't ban crunch; it removes one of the situations that reliably produces it.

The most common error is reading crunch as a measure of commitment, because a team still at their desks at midnight looks like the team that cares most. But needing crunch at all is usually a signal that estimates or scope decisions didn't happen in time. Once it reads as commitment, people start choosing to stay late instead of raising the problem early, and the fact that something is slipping surfaces even later than before.

The other misreading is that a crunch which worked once can be used again. Two weeks of long days that saved a delivery date leaves a strong impression. What often made it work was the slack the team still had going in. Run them back to back and the same two weeks produce less while defects and resignations go up. Teams that schedule crunch into the plan in advance never have that slack to begin with.