rc3.org

Strong opinions, weakly held

Don’t order your team to work more hours

Today I was talking to a friend about his job. He said his company had just had a meeting where the management told his team that they were not satisfied with the overall sense of urgency and that the team needs to be getting things done more quickly. Reading between the lines, it was clear that what the manager meant was that the team needed to be putting in more hours.

Working more than forty hours a week is hardly outside the norm in software development, but directly demanding more hours from people is a bad idea for a number of reasons. I won’t get into basic issues of justice and decency and instead focus only on effectiveness. Even if your only goal is to get things done as quickly as possible, demanding that your team work more as a group is still a bad idea.

The first issue is morale. Members of the team will not readily accept “work more hours” as a possible solution to any problem if other solutions that don’t require them to work more hours are apparent. If there are process changes that would make the team more productive, they’ll wonder why those aren’t being made instead. If there are underperforming members of the team, others will wonder why those team members aren’t being specifically urged to do a better job or being replaced.

And, of course, some team members will start asking themselves why they’re working at a place where the management tries to solve problems using the blunt instrument of “work more hours.” In the end, you wind up with an unhappy team that starts losing its strongest contributors to other jobs. If you do plan to go this route, understand that the team will hold you accountable for every second of their time you appear to waste, so you’d better have your ducks in a row.

The second issue is quality. This is an issue I touched on when I talked about the problem with all-nighters. When someone is working and they know they could be doing something else, whether it’s having dinner with the family, going to their kid’s soccer practice, or sleeping on the couch, chances are their focus is going to be on doing whatever it takes to finish as quickly as possible. Corners will be cut. The longer the team is working extra hours, the more technical debt you build up, which in turn makes it harder for developers to get things done, requiring even more work to maintain the same level of production. It’s a losing proposition.

The third reason not to fall back on “make them work more hours” as a strategy for increasing productivity is that it reduces the organization’s capacity to manage a crisis. For one thing, there are fewer hours to throw at unexpected problems. If your lead developer is already working on Sundays, those Sundays aren’t available when you get a surprising feature request from a big customer. If the team is already burnt out from previous death marches, they’re going to be pretty cynical when their confronted with an actual crisis. And finally, when the crisis arises, that crappy code people were writing at night when they were trying to watch Glee at the same time is going to be an impediment to solving whatever problem is at hand.

The funny thing is that on a good team, you never need to ask people to work more hours at all. If you have good people and they understand and have bought into the team’s goals, then they will do what needs to be done to ship, even when it means putting in extra hours. One way to make sure that never happens is to coerce them into working more hours.

Every time you’re tempted to do so, sit down with members of the team and ask them how many hours a week they spend dealing with stuff not related to shipping and work to make those things go away instead.

6 Comments

  1. To highlight your last point – One of my managers once described his primary job function as something along the lines of “keeping the crap away from you guys so you can get stuff done.” He was one of my best, most effective and (via his team) most productive managers.

  2. One place I worked pulled the work more hours stunt because times were tough. (Not for senior management of course who were all competing to drive the newest Jaguars.)

    What had been happening before was that everyone was already working more hours because they wouldn’t leave work until finishing whatever it was they were working on. After this edict everyone left immediately on finishing time and as a consequence were actually working less total hours.

  3. I’ll never forget the speech the CEO at Interpath gave when he told us we were custodians and we needed to work more hours. Brilliant leadership. Great post.

  4. Jeff – was that the same one that he told us all to find new skills or find new jobs? That was my favorite. But ultimately we did what he said…and found new jobs.

  5. Your point about needing headroom to cover unforeseen events or problems is a good. Run pedal-to-the-floor all day long, and you won’t have that headroom when you need it.

    One also needs time and freedom to step back and think creatively about how to automated and otherwise work smarter and not harder. Creativity tends to go out the window in the face of stress, in favor of tried-and-true, “just get it done so I can go home” methods.

  6. Jonathan: Similar to your first point, one of my former managers would always ask “What has to not go wrong for this plan to succeed?” If the answer is “everything” then you have the wrong plan.

Leave a Reply

Your email address will not be published.

*

© 2016 rc3.org

Theme by Anders NorenUp ↑