The Hawthorne Effect Revisited
A recent article on BBC reminded me of the well-known Hawthorne Effect. Or maybe it isn’t as well-known as I thought.
A factory in the Chicago area, the Hawthorne Works, commissioned a study in 1924-32 “to see if their workers would become more productive in higher or lower levels of light” (quoting Wikipedia). There was a temporary increase in productivity during times when they changed the light levels in the factory, and then productivity leveled off where it had been before.
This sort of temporary effect has been observed many times in many situations since that time. Many people have tried to understand how and why this effect occurs. The only thing people generally agree on is that the light levels as such were not the cause of the change in productivity.
The BBC article celebrates improvements in worker creativity at Valorem, a technology company in Kansas City, MO. They moved employees to a new facility that had been carefully crafted with spaces designed to encourage creative thinking and decorated in colors believed to facilitate calmness and focus. As I write this, they haven’t been there long enough for the initial improvements in creativity to fade. We’ll see how it goes.
My meandering mind takes me to one of the holy dogmas of Agile: the “stable team.” The idea is that software development professionals can function more effectively if they are organized into teams whose membership remains the same over a long period of time. Originally, it was a reaction to some of the problems caused by “matrixed organizations,” in which individual workers were assigned to multiple projects concurrently, and no “true” teams existed.
People spent almost all their time in a state of churn as they navigated the insane number of dependencies that had to be coordinated in order to complete any work. Let’s not mince words here: “Almost all” means nearly 100% of their time. Process Cycle Efficiency in corporate IT shops was typically in the range of 1% to 2% (in my experience). In that context, the stable team concept was a practical remedy for a key issue. Combined with other ideas from the Agile movement, it made a positive impact on the world of IT.
Like most things associated with the Agile movement, the idea somehow became baked into the Agile religion. I may have mentioned this before, but many Agile practitioners today take it as given that teams must be stable, and most of them can’t really explain why. Many Agile coaches will absolutely insist their clients establish stable teams, even in circumstances that call for a different model. Decisions made on the basis of dogma are ever thus.
There’s another religion in the world, too. It’s the religion of “design.” Certain colors cause specific shifts in the human brain. High ceilings engender expansive thinking. Certain shapes of office furnishings facilitate collaboration and stimulate creativity. Et, cetera, and et cetera. The BBC article is all about those soothing hues of blue, the inspiring high ceilings, the mood lighting. <shrug>Maybe there’s something to it.</shrug>
What seems to occur is this: When you change the work environment, there’s a temporary boost in morale, focus, energy, creativity, and effectiveness (unless you make the work environment worse, of course). That’s only one interpretation of the behaviors observed at Hawthorne and elsewhere. If the interpretation is correct, then there’s a risk long-term stable teams would lead to creative stagnation. Anecdotally, I’ve seen Scrum teams that have been “sprinting” for a long time experience this.
The stable team concept was helpful when the “matrix” model was king in corporate IT. Today, most organizations already have some sort of team work spaces, some sort of relatively small and somewhat cross-functional teams, and work on shorter cadences than in the 1980s. Unicorns and rainbows are yet to come, but at least we aren’t in the 1980s anymore. The implication is that 1980s remedies may not be useful.
In many contemporary organizations, demand for software development and support shifts across different applications and platforms. With stable teams in place, some teams are overloaded while others are idle. A model that may align better with contemporary needs is one in which teams form around emerging demand.
In the 1980s, IT departments usually formed teams around emerging demand, but it didn’t work well because individuals tended to be specialists, organizations had low-trust cultures, and performance management systems created a cut-throat competitive atmosphere. The stable team idea was a solution to this. But people weren’t accustomed to working with different colleagues whom they didn’t know or trust, largely due to the stack ranking performance assessment scheme.
The old Tuckman model of “storming, norming” etc. made some sense in a world where individual developers were pitted against each other for raises in a stack ranking system, and where everyone guarded their “weaknesses” so they wouldn’t be undermined by colleagues trying to set themselves up for a positive performance review. When everyone shows up for the first team event with guns drawn, there’s bound to be some “storming.”
It isn’t as relevant in a world where most software developers are comfortable showing their work, and their warts; a world where most developers (the good ones, anyway) participate in code dojos and contribute to Open Source projects, routinely working with people they don’t know; a world where management sets expectations of collaboration for performance reviews. “Storming” isn’t the issue it used to be. Teams can form quickly around emerging demand without much (if any) team-formation stress.
So, what about furniture and lighting? Snacks and games? Comfy chairs and psychological color schemes? Maybe it’s the process of changing things up that makes a difference in creativity and effectiveness. Maybe it isn’t as important exactly what the changes are. Maybe painting a blue wall orange is just as good as painting an orange wall blue. Maybe the color blue isn’t magical, after all. It helps because it’s a new color. Six months later, it’s the old color.
Maybe it ties back to another of my pet peeves: treating humans as “resources.” (I may have mentioned this once or twice, but I’m not sure.) According to Wikipedia, one critic of the Hawthorne results “points out that the Hawthorne tests were based on industrial psychology and were investigating whether workers’ performance could be predicted by pre-hire testing.” This is a goal that would only occur to someone who believed humans were “resources.”
Other analysts of the results observed human responses by test subjects, ranging from knowledge they were being observed to a desire to please the experimenters to suspicion of the experimenters’ motives to excitement about the “new” to you-name-it. Anything and everything except the mechanical and predictable behavior of a “resource.” I submit it is impossible to interpret the Hawthorne results from the perspective of humans as resources.
In my experience, the advice offered by Tom DeMarco and Tim Lister in their classic book, Peopleware, is as relevant today as it ever was. If you want people to work in a collaborative fashion, create workspaces that make it easy to do so. Easy for humans, not resources. A collaborative work area for whole-team activity. Semi-private areas for small group collaboration. Private areas for thinking, personal calls, and one-on-one discussions. Should the walls be blue or green? If you like blue better than green, paint them blue. Better yet, cover them with writable whiteboard material.
Here’s another angle: Animals. Two of the most effective software development environments I’ve worked in had dogs in the office: Lean Dog in Cleveland, and the now-defunct All in Mexico City. Dogs interact with humans (not with resources) in ways that tend to calm people and improve their mood. They wander from person to person to sniff them and make sure they’re okay. They let you pet them, which has documented positive effects for people. They share your snacks. They make you smile, whether by squirming around upside-down to scratch their backs or scooting through the office on a skateboard. (Here’s to you, Otis.) They provide opportunities to enhance your humility, in the form of small messes for you to clean up. All good, but nothing that would make any difference to a “resource.”
According to Wikipedia, social psychologist “Richard Nisbett has described the Hawthorne effect as ‘a glorified anecdote,’ saying that ‘once you have got the anecdote, you can throw away the data.'” I wonder of all the effort to come up with a mechanical model to force “resources” to be more productive is really wasted on humans. Or maybe I’m wrong. Let’s ask BBC to do a follow-up on Valorem twelve months from now, and find out.