Tales of the Rampant Coyote
Ye Olde Archives. Visit the new blog at http://www.rampantgames.com/blog/ - and use the following feed: http://rampantgames.com/blog/wp-rss2.php
Ye Olde Archives. Visit the new blog at http://www.rampantgames.com/blog/ - and use the following feed: http://rampantgames.com/blog/wp-rss2.php
Tuesday, August 01, 2006
Overtime Rant - Kinda
Folks who know me know one of my pet peeves is overtime. Well, the mandatory or pseudo-mandatory kind. I've worked at places that had entire teams on mandatory 60-hour overtime for six months at a time. And I've heard horror stories of far worse. I've possibly blown interviews in the past because, when they ask if I have questions for them, one of the questions I almost always pull out is, "What do you do to prevent crunch times and limit overtime?"
I guess this makes interviewers nervous that I'm not willing to put in the time to make a project succeed. That's not the case, and I try to make that clear when I phrase my question. It's not like I'm afraid of overtime. I've done my share of 60, 70, 80, and even 90-hour work-weeks during my career (the last two still give me nightmares, though, and it's been years). I've done it voluntarily. But I still consider it to be a failure of management.
I just don't really want to work at a company that expects to play fast and loose with the hours that make up their employee's lives.
Poor Management
I got pissed at a former job when, the second day into a brand-new, multi-month project, our new manager did a seat-check at 8:00 in the morning, and loudly proclaimed that WE were screwing up, because there's no way we were going to get the project done on less than 50-hours a week.
My response (not given directly to her, I hadn't begun my new job hunt yet) was, "If we've just started this project and we're already behind by that much, then you (meaning management collectively) are the ones who screwed up. You are admit to deliberately miscalculating the manpower and / or effort needed to get this project done. You are showing disrespect to your employees by not giving them a task that can be reasonably completed using normal work-hours, and then showing further disrespect by chewing them out as if it is THEIR fault."
I still acted like the good little trooper and put in about 50 hours that week. And the next. And I think 55 the next. She still complained when people weren't there as early as SHE was there, yet she didn't see all the people who were working late, long after she'd gone home for the night.
Unsurprisingly, the project went way over schedule, and ultimately failed.
Artificial Deadlines
On another occasion, I was on a team of about 4 guys assigned with a task of getting a budget game out the door in --- well, really, we were told 90 days to get it into beta. We worked our butts off. That's where those 80 and 90 hour work-weeks in my career came from. As the third month hit and we realized "Holy crap, we may actually be able to pull this off!" We contacted the corporate guys to make sure they were in the loop and that they were getting the trademarking, title search, marketing, box art, distribution / duplication slot, and all that other stuff done.
After all, we were working on shell art and stuff at this point, and we kinda needed to have a title for our game for the menu screens, right?
The folks we talked to gave us a response that was akin to (but more polite than), "WTF?"
After some digging, we found that our schedule was a little different from their schedule. To some degree, our schedule was artificially imposed, and nobody expected us to actually make that ludicrous deadline we had been given. So the legal and marketing teams barely had the game on their radar, and figured they had another three months to worry about it.
That experience - and the revelation that came with it - probably burned me out harder than the entire previous four years working crazy hours in the games industry.
And Here Is How It Should Work.
So I just came off of a 12+ hour work-day. And I'm facing another one tomorrow. And probably the next day. This whole week is looking kinda psycho. But my complaints are minimal, and I'm NOT blaming management. Why not? Because:
#1 - I committed to a time schedule that I provided, and I was NOT under any significant duress to shave my figures.
#2 - Because of unforseen side-tasks, poor estimation, or just not working at peak efficiency (really a combination of all three), I found myself falling behind.
#3 - My management has also been working with me to find other solutions to scale back my tasks (or offload them), so other options have been pursued.
#4 - I'm the one who is making the decision to put in the extra hours to help put me back on schedule.
What it comes down to is that I was involved in the management of my tasks. I'm the guy that committed to it, and so if it was a management mistake, I was a part of it. And I'm working with my management to take the necessary steps to rectify the situation. I'm actually pretty embarassed about it, truth be told. It's not been a chronic problem here. So from my standpoint, working a few extra hours is a "last resort" that makes sense - the other options are being pursued, and the hours are something that I have direct control over.
This is how things are SUPPOSED to work. This is no big deal. I wish that this was understood throughout the software industry as a whole. It works when:
- Employees are invested in the project, and feel they have a stake in it
- Employees work WITH management in scheduling (and in the resolution of scheduling issues)
- Employees are not pressured to underestimate their projections to fit an already pre-defined schedule that management made without their input, or to meet an arbitrary deadline
- Management seeks alternative methods of adjusting workload before considering overtime
- Overtime isn't overused.
If you set up a work environment like this, and professionals will often voluntarily put in extra effort to get the job done.
Labels: Biz
Comments:
Links to this post:
<< Home
Well, first:
Waterfall development == Overtime and Bugs. It's stupid, silly and ridiculous (and redundant, apparently) to expect exponential growth of functionality based on hours worked.
Agile management has developed fantastic results in my environment. Fewer overtime hours, more functionality sooner - the whole implementation has been damned impressive.
As for employee buy-in aka "pride in your work" only one thing I've seen produce results: honesty and encouragement from management, with clear expectations. Have them work 1-2 hours overtime rather than a crunch. Move deadlines or expectations.
Waterfall development == Overtime and Bugs. It's stupid, silly and ridiculous (and redundant, apparently) to expect exponential growth of functionality based on hours worked.
Agile management has developed fantastic results in my environment. Fewer overtime hours, more functionality sooner - the whole implementation has been damned impressive.
As for employee buy-in aka "pride in your work" only one thing I've seen produce results: honesty and encouragement from management, with clear expectations. Have them work 1-2 hours overtime rather than a crunch. Move deadlines or expectations.
I agree 100% on Waterfall. I think Waterfall has it's place... in VERY VERY specific (and rare) situations. Things like designing missile guidance systems, or maybe ATM software. Mission-critical stuff... especially where lives may be at stake... that have very fixed and unchanging usage and operating environments.
I've worked in one place with Agile, and it worked pretty well. I was impressed. Can't say I'm a complete true-believer in any specific agile process, but it made a lot of sense and actually worked well in the REAL WORLD. Which to me makes all the difference.
I've seen employee buy-in work REALLY well in the past. I've also seen managers ATTEMPT to gain employee buy-in only after the fan is spraying smelly brown gunk everywhere. That trick rarely works. It's one thing for a manager and employees to work together as a team. But it's another thing for employees to feel like they have just been stuck covering their manager's butt (and feeling they are gonna be stuck with the blame when they don't). The difference is at what point management decided to actually treat their staff like members of the team and actively involve them in the decision-making.
Post a Comment
I've worked in one place with Agile, and it worked pretty well. I was impressed. Can't say I'm a complete true-believer in any specific agile process, but it made a lot of sense and actually worked well in the REAL WORLD. Which to me makes all the difference.
I've seen employee buy-in work REALLY well in the past. I've also seen managers ATTEMPT to gain employee buy-in only after the fan is spraying smelly brown gunk everywhere. That trick rarely works. It's one thing for a manager and employees to work together as a team. But it's another thing for employees to feel like they have just been stuck covering their manager's butt (and feeling they are gonna be stuck with the blame when they don't). The difference is at what point management decided to actually treat their staff like members of the team and actively involve them in the decision-making.
Links to this post:
<< Home

