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.
Optimize for simplicity, not performance
I liked this, from DHH:
That can be a tough lesson for those of us who have been developing software for awhile to internalize. It becomes ever more sensible to optimize for simplicity rather than performance.