The Case for Rest
As I looped around the east edge of Phoenix, heading home from the GigaWorld IT Forum, I heard NPRs salute to National Night Shift Workers Day conclude with a poem by Karen Jane Glenn. "Let us now praise the night shift," she began. "Those on the 8-to-4, the 10-to-6 ... the sleep-deprived ... the wired." I could relate. It seems as if every week brings me more e-mail messages that are time-stamped during the interval that Navy men call the midwatch, from midnight to four in the morning. And I have to admit that Im also sending more of those midwatch messages myself.
As it happened, the theme of the conference Id just attended was "Deliver more with less." I dont remember seeing "less sleep" as a formal part of the agendabut as I listened to Glenns poem, it seemed as if that topic should have been addressed. After all, National Science Foundation statistics estimate U.S. adults averaging less than 7 hours sleep at night; other studies point to sleep-deprivation effects that include difficulty following discussions; poor judgment in complex situations; difficulty in devising a new approach to a stubborn problem; and failure to notice changes in situations.
In practical terms, this means that people arent functioning as well as they should in everyday situations such as planning a project, responding to a cyber-attack, debugging an application or monitoring network operations.
Spread thin by staff reductions, and losing formerly productive time to diversions such as extra security delays in airports, people are putting in 10-hour and even 20-hour days for what used to be considered 8 hours pay. That may not be as good a deal for the employer as it first seems, if the extra hours represent neutral or even negative contributions. Yes, its great that people can work at any time, from anywhere, but sleep-deprived zombies arent the shock troops of enterprise successwhether theyre "the wired" of Glenns poem or not.
International operations can approach the 24-hour day as a relay race, rather than a marathon. IBM, for example, has adopted a two-shift approach to some of its software development efforts, with teams in Seattle setting daily work specifications for offshore teams in India, China, Latvia and Belarus. Overnight offshore development returns product to Seattle the next day for review, and the cycle continues.
The company says this process reduces development cycles by 35 percent, yielding time-to-market benefits that are worth even more than the reductions in development cost. Note well that this is not about stretching a given number of people across a greater number of hours: Its about taking advantage of the 24-hour day in operations that circle the globe.
The problem with success stories like this is that smaller companies may feel that they must do likewise. Im reminded of former Avis CEO Robert Townsends warning that some corporate behaviors dont scale well from large to small organizations. The smaller company that decides to open an office in Bangalore, or outsource some of its operations to a contractor in Tel Aviv, may find that it has blunted its competitive edge of being able to get close to its customers and thoroughly understand their needs. Being just like IBM, only a hundred times smaller, is like being a miniature elephant in an ecological niche thats better suited to a fox.
In organizations of every size, managers need to avoid letting IT push their people across the line that separates anytime/anywhere flexibility from all-the-time/everywhere expectation. When intermediate deadlines start being regarded as purely pro forma, and everyone knows that the real schedule squeezes three days on the timetable into a 24-hour all-nighter at the end of every product cycle, thats a cultural problem that has to be solved by cultural forces. When managers treat crash-and-burn schedules as a sign of commitment and not as a problem to be fixed, thats a cultural force that pushes in the wrong direction.
C. Northcote Parkinson was right: Work does expand to fill the time available. IT can make that available time appear to be "all the time." Im not saying that our e-mail systems need a curfew. I am saying that the human side of management includes making it clear that you want good hours, not just more of them.