How do I tell my team to work more hours to hit a launch date?
theeffectiveengineer.com
theeffectiveengineer.com
For those cases where it is useful, I would add: * Make it more fun to work than not to work. Bring in dinners. Invite their families to visit in the evening. Acknowledge that you're camping out. * Remove non-work obstacles and distractions. Drive people to and from the train station or their homes. Help them find babysitting. Do their laundry (yourself, or hire a service). * Remove work obstacles and distractions. If you're in a big company with bureaucracy, run interference. Explain that the team is in crunch mode, and do or defer their expense reports, training procedures, and other overhead. * Have a nap area. I've only been at one company that had a formal nap room, but everywhere else has gone through cycles of using a conference room or out-of-the-way sofa, and then hiring enough people that there's not space for that any more, and then getting more floorspace, and repeat. During the phases when there's not an on-site nap room, people either home in the evening and don't come back, and/or turn braindead and might as well be gone. * Have an end in sight. If there's not a natural exogenous deadline (such as an industry event), fake one (this has to be the Solstice release because reasons). It's particularly important that crunch mode be timeboxed, not feature-boxed; if you've been in feature-milestone mode, now's the time to pivot. * Work longer hours yourself. A leader should be first in, last out.
This is big. If you tell a team of developers "Project Frozgibbit has to be done by Sept. 13th" and they ask why, the answer better not be:
"Because marketing told a bunch of industry analysts we were shipping on Sept. 13th".
Why not? Because, consciously or subconsciously, the developers are going to be thinking "How is it my problem that marketing is staffed with idiots and announced the date before we knew when it would be ready?" They're going to wonder why marketing doesn't understand agile development and an iterative, empirical, feedback based approach to software delivery, and doesn't base their announcements on realistic data, OR, accept that it's OK to change an announced release date. In other words, from the developers' standpoint "Poor planning on your part, does not constitute an emergency on my part".
Now, IF the answer to the original question is "Because we just found out that EvilCorp, Inc. has announced that they will be shipping Glizbrikkit 3.0 in September, and we need to be able to demo Frozgibbit to analysts, press and customers at the SuperGrommit Conference (which is on Sept 17th) in order to counter their momentum" then most developers will (if somewhat grudgingly) accept that and willingly knuckle down and put in the extra effort. In fact, the more competitive team members may get really psyched up for a little head to head competition...
It's GoodCorp vs. EvilCorp, dude... this is Rocky Balboa vs. Clubber Lang, the Karate Kid vs. Johnny Lawrence, Cru Jones vs. Bart Taylor, good vs. evil. Cultivate a little bit of that spirit and people will run through walls.