Scarcity: Why Having Too Little Means So Much (23 page)

Satellites like Orbiter are built piecemeal by several subcontractors. The thrusters, built by one firm, were interpreting the input they were receiving in pounds, the English system measurement of force. The central processor, built by a different firm, was providing the input in newtons, the metric system measurement. Every time the processor said “X,” the thrusters heard “4.45 times X.” (When the processor said “10,” that meant 10 newtons, but the thrusters heard “10 pounds,” the equivalent of 44.5 newtons.) The result: Orbiter slowed down too much and got caught in the gravitational pull of Mars. For a project of this significance, this was a comical, if highly consequential, blunder.

Errors are inevitable. NASA engineers know this. This is why endless checks and tests are put in place. So what happened? In the months leading up to the launch, the entire team at the Jet Propulsion Laboratory was running behind schedule. They were understaffed
and had failed to turn their attention fully to all the project details until it was late. Everyone falls behind, and it has been observed that organizations that are firefighting tend to allocate smaller teams to new projects, since much of the staff is still helping fight the last fire. Unlike workers in other industries, however, these engineers did not have access to the universal fallback of the tardy—an extension of the deadline. Celestial orbits drive the launch date: the locations of Mars and other bodies determine a narrow launch window. It is hard to negotiate with the astronomical calendar.

The tight deadline created long hours. But it also created tunneling. The focus was on making the launch date. Things directly unrelated to that goal were put off, and as it turned out, they were never returned to. The 4.45 mistake was one such casualty. The engineers’ own data showed there was something wrong well before the launch. They noticed the inconsistencies. But figuring out the source of the inconsistencies was one more task on the to-do list, and with so much left to do, not everything can be done. Following up on apparent inconsistencies was one casualty. Another casualty was a joint simulation of thruster and processor, which would have revealed the problem directly. The usual checks and balances were sacrificed, potential signs of trouble were overlooked, all in order to make the deadline. By now you will recognize this as a logical consequence of tunneling.

This is not hindsight. A NASA report to the Jet Propulsion Laboratory
prior to the crash
highlighted the problem. Initial project delays (perhaps because of understaffing), it argued, were leading to shortcuts and workarounds. Staff were working long hours and making mistakes. The initial delay was generating more inefficiency. Worse, crucial checks—those that seemed less pressing—were being overlooked. The report essentially foretold the pattern that led to the mix-up and eventual crash.

This is more than a symptom of falling behind. Once they established the technical autopsy, the investigators of the Orbiter crash looked to organizational reasons for the failure. One reason, they
concluded, was the “Faster, Better, Cheaper” paradigm that NASA had adopted. This paradigm put an emphasis on cost savings and schedule reduction. Teams started to run short on time and tunneled. And then they neglected. In this case crucial checks were neglected because they were important but not urgent; they were not crucial to the task at hand—to make the launch happen, on time.

Both St. John’s and NASA had fallen into a firefighting trap. As the organizational researchers Roger Bohn and Ramchandran Jaikumar describe it,
firefighting organizations have several features in common
. First, they have “too many problems, not enough time.” Second, they solve the urgent problems but put off the nonurgent ones, no matter how important. Third, this leads to a cascade so that the amount of work to be done grows. Put simply, time is spent on fighting the immediate fire, with new fires constantly popping up because nothing is being done to prevent them. At St. John’s the surgeons were so busy dealing with patients right now that they could not step back and look at the overall patient mix. At NASA the engineers were so busy trying to make the deadline for each component that they did not look at how the components fit together. The firefighting trap is a special case of the scarcity trap.

A thorough five-year study of four top manufacturing firms in the United States documented multiple instances of firefighting. As one manager puts it: “
If you look at our resource allocation on traditional projects
, we always start late and don’t put people on the projects soon enough … then we load as many people on as it takes … the resource allocation peaks when we launch the project.” Based on their years of study, the researchers conclude, “There are few images more common in current discussions of R&D management than that of the overworked engineering team putting in long hours to complete a project in its last days before launch.”

Firefighting
does not just lead to errors; it leads to a very predictable kind of error: important but nonurgent tasks are neglected. Just as the name implies, you are busy fighting the urgent problem (the fire); other problems, no matter how important, are drowned by the most urgent (seatbelts on the way to the fire). As a result, structural problems—important, but they can wait—never get fixed. When Microsoft shipped its Windows 2000 software, it went out with
28,000
known
bugs
. The project team knew they were shipping a product with lots of problems, but they were already behind the deadline. As a result, they immediately began working on a first patch, which was to fix all the bugs they knew they had shipped out. Not a good place to be when reports of new bugs start coming in.

Firefighting traps involve a great deal of juggling. You are so focused on the looming deadline that when you finish you realize the next project is suddenly due. Most of us have found ourselves doing this at one point or another, and we know intuitively that firefighting is a trap for all the reasons scarcity is a trap. Once you start firefighting, it is hard to emerge unscathed. When teams are frantically working on a project that should have already been done, they start late on the next project, which ensures they will firefight there as well and
stay perpetually behind
.

Understanding the logic of scarcity and slack can reduce the chance that we enter a firefighting trap. Yet we know that tunneling makes it easy to overlook other considerations. One solution, at least in organizations, is to explicitly manage and ensure the availability of slack. There is a lesson in how banks have tried to manage risk. Banks have long recognized that managers, tunneling on the bottom line, do not sufficiently take risk into account. As the 2008 financial crisis demonstrated, this is an understatement. More recently, many banks have introduced “chief risk officers,” who sit apart from the rest of the management team and report directly to the CEO. They must approve financial products, loans, and other transactions, viewing them through the lens of risk. Unlike the managers who focus (tunnel!) on the most appealing transactions and on
making the big profits and the sales targets, these executives’ sole goal is to monitor risk.

Similarly, as fat continues to be cut, and slack goes with it, organizations may want someone in-house who is not tunneled on stretching resources. Someone, removed from the daily tunneling, whose job is to ensure that the organization has enough slack and who focuses not on what needs to be done today but on what possible shocks may upset tight plans tomorrow. Someone must ensure that those who are focused on meeting immediate project targets are not borrowing from future projects, thereby exhausting any slack and digging the organization deeper into a bandwidth hole in the future. It is not a coincidence that the adviser that St. John’s hired was clearly removed from the struggle for the next operating room.

The truly efficient laborer
will be found not to crowd his day with work, but will saunter to his task surrounded by a wide halo of ease and leisure.

—
HENRY DAVID THOREAU

There is another lesson to draw from the NASA experience. When the Jet Propulsion Laboratory crew started to fall behind, management did what most managers would do. They increased hours. They saw a scarcity of time—Orbiter must launch soon—and they deployed more time to address it. This is a common response to time scarcity. A project is running behind schedule? Put in more people on the problem to get caught up. And if an organization is stretched for employees—time is pressing, and hiring and training new people will take time—simply work your people more hours, at least until new employees can be brought in. On the surface this seems like an obvious solution and the easiest way to do more with a fixed amount of
resources. Yet this response may not be as sensible as it seems. It recognizes one form of scarcity—time left to finish the project—but it ignores another form of scarcity—bandwidth. It neglects the consequences of reduced bandwidth on performance.

Consider the use of cell phones.
Ten states now ban the use of handheld cell phones while driving
. This makes some sense, and other states are sure to follow. After all, with only one hand on the wheel, you are bound to be a less efficient, less responsive driver. But this also makes a major, if hidden, assumption. As it turns out,
drivers holding a cell phone
are significantly more likely to get into an accident, but
so are drivers using a headset
. The hands are not the problem—the mind is. In one simulation study, drivers using hands-free phones
missed twice as many traffic signals
compared to those who were not on the phone. We naturally think of driving as an activity requiring physical resources, but safe driving requires more than two hands; it requires bandwidth as well.

Similarly, we often overlook bandwidth when arranging our time. What we naturally think of is the time it will take to complete our to-do list, not the bandwidth it will require or receive. Think of how the Jet Propulsion Laboratory engineers responded to the problem of the impending celestial deadline. They poured more engineer
hours
into the problem. But that did not necessarily provide more bandwidth, and one can argue that the overworked engineers may have given their work
less
total bandwidth despite the longer hours.

Nearly a century ago, Henry Ford recognized the distinction between hours and bandwidth. His decision to institute a forty-hour workweek for his factory workers was clearly motivated by profits as much as by humanitarian concerns. As one commentator observes:

When Henry Ford famously adopted a 40-hour workweek
in 1926, he was bitterly criticized by members of the National Association of Manufacturers. But his experiments, which he’d been conducting for at least 12 years, showed him clearly that cutting the workday from ten hours to eight hours—and the workweek from six days to five
days—increased total worker output and reduced production cost. Ford spoke glowingly of the social benefits of a shorter workweek, couched firmly in terms of how increased time for consumption was good for everyone. But the core of his argument was that reduced shift length meant more output.

Finding the data on Ford’s original experiments is difficult. But several similar studies have been run in almost a century since Ford’s experiments. One study, on construction projects, found that “
where a work schedule of 60 or more hours per week
is continued longer than about two months, the cumulative effect of decreased productivity will cause a delay in the completion date beyond that which could have been realized with the same crew size on a 40-hour week.” In a very different industry,
a software developer notes
that when his staff began putting in sixty-hour weeks, the first few weeks would see much more work getting done. But by week five, the employees were getting less done than when they had been working forty-hour weeks.

Another study looked at what happened in a cardiothoracic surgery department when
the number of patients per medical service worker
increased. Again, there was an increase in productivity in the short run. Patients were dealt with more quickly. But this came at a cost. There was neglect. Dealing with more patients quickly lowered quality: patients were more likely to die. In fact, even the benefits did not persist. A sustained increase in workload eventually led to an
increase
in the time it took to manage each patient.

The impact on productivity can also show up in other ways. Here is one researcher discussing innovation in the workplace:

At the end of each interview
I asked the interviewees what they would do first to encourage innovation in their organization if they were suddenly omnipotent. By far the most common answer was time. But respondents often qualified this—they didn’t want more of the same kind of time, they wanted more unstructured time that did
not have specific outputs or procedures attached to it. The managing director … put this very well when she yearned for “time to play … time to gaze out the window … time to let things settle … time to read and react.”

In a way, none of this should be surprising. Just as we get physically exhausted and need to rest, we also get mentally depleted and need to recover. Instead, with prolonged scarcity, bandwidth taxes tend to accumulate. To understand the mechanism, consider something as simple as sleep. People with time scarcity who are working more hours will try to squeeze more into the remainder of each day; they will neglect and patch things. Sleep is one obvious candidate. When you run out of time, you sleep a little less and squeeze in a few more hours of work. Yet the effects of sleep on productivity are striking. Studies have repeatedly shown that
when workers sleep less
they become less motivated, make more errors, and zone out more often. One clever study demonstrated this by looking at the start and end of daylight savings time, nights on which, because of the time change, people lose sleep. It found that people spent
20 percent more time cyberloafing
—searching the web for unrelated content—for every hour of lost sleep on those evenings. And that is just one night of sleep. Research shows that the cumulative effects are far worse. As work hours accumulate and sleep time diminishes, productivity eventually goes down.