What I meant here is that you have to fix an occasional bug and ship an occasional feature, but only in order to remain an effective tiebreaker. Fixing things is no longer your primary job. During crunch time new managers often feel that the best way to help the team is to dig in and fix things themselves, but in reality they can help much more effectively by doing other things.

So fix an occasional bug, but remember, you're only doing it to stay in tune with the codebase, not to ship things faster.

> What do you mean by tiebreaker?

I'm talking about making decisions when half the team thinks "we should do X" and the other half thinks "we should do Y". If the team can't reach consensus someone has to decide, and as a manager, that's you.

Is "crunch time" a good thing in software development? It's certainly possible to deliver software without crunch times.

This day could be called "crunch time" even if no external deadline is handed down.