A manager's main job is to make crunch time not happen. Crunch time is management failure to plan.
>During crunch time
Is "crunch time" a good thing in software development? It's certainly possible to deliver software without crunch times.
Re:Engineering management lessons
by HeyLaughingBoy on Friday October 03, 2014 @05:36PM
(#8407770)
No, it's a spectacularly bad thing. Unfortunately most dev cultures assume that it will always be necessary. In pretty much all cases it's a management failure.
Re:Engineering management lessons
by prostoalex on Friday October 03, 2014 @06:47PM
(#8408060)
But yet there's a day when you're ready to release, and therefore need to coordinate with engineers on monitoring the release and fixing last-minute bugs and dependencies, with ops on deploying the release, with marketing on writing a blog post, and with sales on communicating the features to the customers.
This day could be called "crunch time" even if no external deadline is handed down.
Re:Engineering management lessons
by stevewilhelm on Friday October 03, 2014 @05:35PM
(#8407763)
While "crunch time" might not be a good thing in software development, it's essential to a growing business.
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.